<pashencija[m]>Had hard time getting it to work because it could not resolve localhost (no binding to 127.0.0.1 in /etc/hosts) <acrow> pashencija[m]: You could modify your config.scm to add that binding in /etc/hosts... <pashencija[m]>It was on arch. I meant to send it about another problem to another chat. It's night here <antipode>sneek: later tell mala: I don't know if you can do that in the REPL, but in Guile programs, you can use 'continuable exceptions' to do things like that (try raise-continuable+with-exception-handler), and remember to _not_ use catch which doesn't preserve continuability) <lilyp>Using debian to nuke Guix is somewhat ironic, given that it's usually the other way round. <lilyp>pashencija[m]: do you have a vague idea what kf5 might be looking for? <lilyp>I suppose it's something from the kde suite rather than pure qt <shcv[m]>is there a way to have `guix shell` start a different shell? I think my zsh configs are messing with the way it sets envars <shcv[m]>at some point I need to figure out how to use guix home to manage that <pashencija[m]><lilyp> "pashencija: do you have a..." <- It works now. Thank you! <KE0VVT>shcv[m]: systemd-homed lets you keep your home dir encrypted while your laptop is on suspend. It also lets you physically detach it as an encrypted flash drive that can be shared between computers. <shcv[m]>doesn't sound too hard to replicate, but maybe I don't know what I'm talking about <KE0VVT>shcv[m]: So, when you're not logged in, your data is just... not there. <KE0VVT>shcv[m]: Also, everything about your user is contained in the home directory. There is no /etc/passwd. <shcv[m]>then how is the decryption performed? <KE0VVT>shcv[m]: I think there's some minimal information kept in /home/ in place of the home dir. <KE0VVT>shcv[m]: I'm not sure on the details. I just watched a demo of systemd-homed a long time ago. <lilyp>shcv[m]: I think guix shell uses your current shell as base, so simply start bash from zsh, then guix shell <lilyp>to be fair, guix home lets you keep an unencrypted copy of all your config :P <KarlJoad>How can I use a file in a local directory to test my substitute* regexp in a guix repl? <shcv[m]>lilyp: when I run guix shell from bash, it starts zsh again... I think it's running it because that's my user shell? <nckx>KarlJoad: Just… do? There is no daemon/magic involved. <KarlJoad>nckx: Ok... I guess my syntax is just wrong then. <nckx>KarlJoad: I have a minute. What's your syntax? <KarlJoad>(substitute* "module.lisp" (("\(pathname-as-directory [a-zA-Z\(\)/.\"]*\)" "test"))) <KarlJoad>guix-repl is running in the directory with module.lisp too. <KarlJoad>The repl is complaining about a "bad let in form" <KarlJoad>Nevermind. I got it. Needed to move a parentheses around the regexp. <lilyp>shcv[m]: (define %default-shell <lilyp> (or (getenv "SHELL") "/bin/sh")) <NaturalNumber>anyone know why installing a simple package takes a long time at the last step, building a new profile, and causes my inode usage to drastically go up? thx <sneek>Welcome back NaturalNumber, you have 1 message! <sneek>NaturalNumber, antipode says: NaturalNumber: Are you using Nix somewhere? Maybe one of the NIX_... environment variables are set, leading Guix to talk to the nix daemon instead of the guix daemon. <acrow>vagrantc: There is more code to share. :) <KarlJoad>Can I add a list of patches to an inherited origin without needing to re-write the origin record manually? <KarlJoad>podiki[m]: Perfect! Exactly what I want to do! Thanks! <podiki[m]>and that's the general scheme with inheriting, things override if you write the same field (like arguments) but you can instead modify the inheritied package fields (as lists of strings I believe) <KarlJoad>Ok. I need to look into the construction of the package record and its component fields. I got the inheriting part, but am still getting familiar with what can be inherited and how I can manipulate it. <KarlJoad>Changing the patches list is different than changing the arguments key-value list for instance. <KarlJoad>On another note, can I change %patch-path so I can do (search-patches "patch") in my personal channel? <podiki[m]>if it is a local file you can just point it to the path (I think just '("/path/to/patch")) <KarlJoad>Fair enough. I just want to make my channel mirror Guix as much as possible is all. <KarlJoad>Because now I am trying to resolve the patch's location relative to the CWD of the shell where I start the build. <podiki[m]>I think you just need the patch in your channel (where you've pulled including that channel) for it to find it with search-patches? I forget if you need to define anything else <podiki[m]>just make sure it was added (with git) and you have pulled with the channel, I think <KarlJoad>I have added it to the repo that is the channel. I have not pulled the channel since though. But, I have the directory in my load path with -L. <KarlJoad>podiki[m]: With '("stumpwm-module-dir-easy-regexp-replace.patch") I get an error on canonicalizing the path, and (search-patches "stumpwm-module-dir-easy-regexp-replace.patch") I just get an error. <KarlJoad>But with '("synnax/packages/patches/stumpwm-module-dir-easy-regexp-replace.patch") AND running at the root of the channel, everything works. <podiki[m]>not sure, I would just use the absolute path maybe? <KarlJoad>Also, is I did try with a leading . (./synnax/...) and it did the same thing. <KarlJoad>Now my build is failing because of "cycle detected in the references of #$out" <podiki[m]>(funny just went back to stumpwm and was seeing the discussion on module-dir...) <KarlJoad>Yeah... That's been a fun issue to tinker with all day... <KarlJoad>I _do_ manually add a reference to #$out in a file so it can find its modules. Is that not allowed? <podiki[m]>dunno; feel free to link a paste to your patch later and I can take look <KarlJoad>I think I tracked it down, but still do not understand why it is happening. In the stumpwm-lib output (where Lisp source files are installed), I manually create a reference to the stumpwm #$out directory. ***Xenguy_ is now known as Xenguy
<podiki[m]>KarlJoad: not sure the details, but not sure why you use a patch. if you want to modify the source (for guix specifically), I would probably just add a phase after 'unpack and use substitute* there <podiki[m]>just as the stump package does with 'fix-tests <KarlJoad>My reason why was because I didn't know a good enough regexp to replace just the argument to pathname-as-directory in `(pathname-as-directory (concat (getenv "HOME") "/.stumpwm.d/modules"))`. The patch was just easier for now. <podiki[m]>and since you say something about the lib output, maybe it is how these are built (i haven't tinkered with the lisp packages in guix) <podiki[m]>if the (concat...) part is unique, you could match to that whole string, though the escaping is annoying <podiki[m]>anyway, good luck for now, happy to help later, feel free to leave a message (either just mention my nick or use sneek) <podiki[m]>(my first guess would be to do this after 'unpack anyway, next would be look at details of how the lib output is constructed in this build system for clues of what's going on) <KarlJoad>I'm thinking the cycle issue is because of the asdf stuff pointing to the stumpwm lisp source, which points to the compiled output, which points somewhere else. <KarlJoad>Has anyone seen this before? `package has an invalid input: ("_" ("sbcl-alexandria"`. It is coming from a package where inputs are defined as `(inputs (append (list new-pkg) (package-inputs original-pkg)))`. <gnucode>well that's weird, issues.guix.gnu.org is giving me a nginx 502 bad gateway error ... <lechner>Hi, I switched to Guix Home. Would someone who uses the Fish shell share their configuration, please? Thanks! <gnucode>I personally just start my shell via termite -e fish, and it autostarts the shell in fish. <lechner>gnucode: i think there may be some benefits in letting 'guix home' handle it, no? <gnucode>lechner: probably. I don't use guix home. I haven't migrated over yet. :) <podiki[m]>for those mentioning above, issues front end has been down for a few days (known problem) <trevdev[m]>Since you guys are "fishy", can you tell me what fish does for you that a more standard shell (such as zsh + plugins) cannot? Fish deviates from the usual command-line/script syntax. I'm stubborn and don't want ot learn a way to shell, but I'm still curious <gnucode>trevdev[m] I prefer it, because when I take 5+ minutes writing out a complicated command, I never have to remember it again. It will help me remember the command. <elais[m]>I like fish because more often than not I get vanilla fish what zsh + plugins gives other people <lilyp>NaturalNumber: re: inode usage, profiles have symlinks to all the packages within them, so if you have a lot of packages, you'll create a lot of extra inodes <lechner>trevdev[m]: like for gnucode, it remembers my workflow---totally <apoorv569[m]>Do I need a `use-module` form for using the `(dependencies mapped-devices)` in the `btrfs` `file-system` definition? Because I am getting this error, `error: mapped-devices: unbound variable`. <gnucode>hmmm, I'm not certain how to finish the final bit on this opensmtpd-filters... <Guest63>i installed guixsd it comes with a default emacs that i would like to remove, how do i know where its defined ? <rekado_>Guest63: is it listed in the ‘packages’ field of your operating system configuration? <rekado_>what does your operating system config look like? <Guest63>it has xfce-desktop-service-type which pulls in some extra stuff like thunar, is there a way to view system packages graph ? <antipode>sneek: later tell KarlJoad: I find it easier myself to do (patches (list (local-file "patch-file-1.patch") (local-file "patch-file-2.patch")), where file names are relative to the location of the module it is used in, IIUC. <antipode>sneek: later tell KarlJoad: (at least, for channels, for Guix itself there's search-patches) ***Dynom_ is now known as Guest9867
<apoorv569[m]>Do I need a `use-module` form for using the `(dependencies mapped-devices)` in the `btrfs` `file-system` definition? Because I am getting this error, `error: mapped-devices: unbound variable`. <unmatched-paren>I'm not sure why it's giving you an unbound variable error; the manual seems to imply that it's an implicitly bound variable... <lilyp>apoorv569[m]: can you paste the config.scm (use paste.debian.net or similar if 0x0 doesn't handle text) <apoorv569[m]>The `config.scm` file works fine as it is auto generated via the `installer`. I have a`base-system.scm` file and multiple other `MACHINE_NAME.scm` files that I am trying to use to configure each system independently by running `sudo -E guix system -L ~/.config/guix/systems reconfigure --verbosity=3 `/.config/guix/systems/machine1.scm` <lilyp>just paste the one that causes errors then <apoorv569[m]>I have redacted some things like timezone and username, for privacy reasons.. <nckx`>Are you not using m-d before it's specified? <nckx`>Wait, where is it specified? <nckx`>If you copy/pasted this from the manual, note that those examples specify a mapped-devices value before using it later. <apoorv569[m]>Do I have specify a `mapped-device` before using in the `file-system`? <nckx`>Only if you have mapped devices. What (dependencies mapped-devices) means is 'yo, make sure you assemble my RAIDs and LVMs and LUKSes before you try to mount things'. <nckx`>If you don't have any, why would you need that? <apoorv569[m]>because that is what the `btrfs` section lists for using subvolumes.. <nckx`>It literally says '...hence the dependency...' above that. If you're not using mapped devices, don't depend on them. <lilyp>you don't define base-operating-system in MachineX <apoorv569[m]>Yes, that is supposed to be inherited from `base-system.scm` because the module `base-system` is defined in that file. in my `machinex` config I include `#:use-modules (base-system)` <roptat>apoorv569[m], this usually happens when there's an error in (base-system) and guile refuses to load the file, then its variables are not defined and it reports only this error <roptat>try to run the guix repl and ,use (base-system) <roptat>that should print a better error <roptat>you must be missing a -L (--load-path) <roptat>the same that you use with the guix system command <unmatched-paren>apoorv569[m]: why are you using (gnu packages neovim), that module doesn't exist <roptat>I don't think we have a lightdm service? <unmatched-paren>greetd is basically a daemon that implements the hard parts of login managers <unmatched-paren>and provides a JSON protocol for 'greeters' like gtkgreet and tuigreet <unmatched-paren>so those greeters only have to implement a UI, not the tricky authentication code <Maya[m]1>i love finding new bugs in guix packages! apparently guix doesn’t change opensmtpd’s smtpctl gid and it doesn’t work! <Maya[m]1>I have found the issue, during the build process the gid does not exist, how should I fix it? Can you create groups during package build process? <Maya[m]1>unmatched-paren: yes, but it runs chgrp during build process and the group is not available <Maya[m]1>i think this is a guix issue, unmatched-paren the executable must be owned by the smtpq group, this is done in a makefile, but the group is not present on buildtime. Is there a way to ensure group existing during build? <unmatched-paren>Maya[m]1: I'm not entirely sure how unix groups work, but i'd think that if you created the group during the build process, then used guix system's opensmtpd service, which presumably creates such a group, they wouldn't be the same group? <Maya[m]1>unmatched-paren: if you’re create them with the same gid i think they will *unmatched-paren opens gnu/services/mail.scm <Maya[m]1>unmatched-paren: i think you can specify gid with user-group and in filesystem there’s only stored uid and gid <apoorv569[m]>let's see if I see further errors... it is downloads lots of substitutes for now. <andrzejku>do you know how to add to services geoclue-service <andrzejku>-> (services (list geoclue-service %desktop-services)) <apoorv569[m]>andrzejku: I think it might be called `geoclue-service-type`. Usually when you added to the `(services ` you also add `-type`. <roptat>the manual doesn't have geoclue-service-type, but it has geoclue-service <roptat>the difference is that geoclue-service is a procedure, so you use it like this: (geoclue-service) <nckx`>The old-style -service names are usually procedures, so you'd need (), but use the new-style -service-type if available. <roptat>I love my bépo keyboard too much, that's why <roptat>(and really, that's because I have a tendancy to reply just before nckx` :)) <nckx`>I have a Dvorak layout on my touchscreen which is like supergluing a spoiler to your Lada. <andrzejku>apoorv569[m]: id doesn't work no value specified for service of type 'geoclue' <roptat>try (service geoclue-service-type (geoclue-configuration)) <roptat>ah there's no default value in geoclue-configuration <roptat>would be easier to use the deprecated (geoclue-service) <andrzejku>ok I think I add it correctly but now there is a build error dbus-system-services.drv failed <roptat>I meant the content of /var/log/guix/drvs/yg/9n3pss34p2xh01lxl2gag7hkawxbk8-dbus-system-services.drv.gz <andrzejku>roptat: I tried tar -tf this file but it is empty <roptat>it's not a tar, only compressed with gz <roptat>do you have a dbus service declared in your system config? <roptat>you could try sharing your os definition, maybe we'll find something in it <roptat>geoclue is already part of %desktop-services, so you don't have to repeat it, do you? <andrzejku>because when I reconfigure with installed geoclue <roptat>geoclue doesn't extend the shepherd <andrzejku>Error: Unable to get location from provider. <andrzejku>roptat: wait maybe I will try to get soem tool to check dbus services <podiki[m]>I believe there is a sample in the geoclue package <podiki[m]>look for the geoclue demo agent and where-am-i I think <podiki[m]>and if you are watching /var/log/messages you should see some output of geoclue being activated <podiki[m]>(mine doesn't get a location but I also haven't tried setting it up) <roptat>200 strings left to translate in the manual :) <andrzejku>well you were right it is but it doesn't work <andrzejku>apoorv569[m]: true but this is more a hack :P <podiki[m]>any stumpwm users here? (just going back after a while away) <KarlJoad>podiki[m]: I know for a fact there is me. <sneek>KarlJoad, you have 2 messages! <sneek>KarlJoad, antipode says: I find it easier myself to do (patches (list (local-file "patch-file-1.patch") (local-file "patch-file-2.patch")), where file names are relative to the location of the module it is used in, IIUC. <sneek>KarlJoad, antipode says: (at least, for channels, for Guix itself there's search-patches) <muradm>is there any news on 56690 (seatd-service-type) and 56699 (greetd-service-type)? <unmatched-paren>muradm: I still haven't packaged the first web framework required (somehow) for tuigreet :( I've had to add updated versions of serde, syn, rust-openssl, quote, and many, many other packages, and I'm still not there yet... <unmatched-paren>according to `git log --oneline 8a5a2a7~1.. | wc -l`: I've made 142 commits to guixrus so far <muradm>is there any news on 56579 (fail2ban) and 56608 (fail2ban-service-type)? <unmatched-paren>keep in mind that this one package is a text user interface that writes json to a socket <unmatched-paren>the rust ecosystem is absolutely insane... if i wasn't already convinced of that, I am now :) <apoorv569[m]>The `guix system reconfigure` is stuck compilation of a file some `bdcsvd_8.dir/bdcsvd.cpp.o` I have been waiting for quite some time now it hasn't moved past this file <muradm>unmatched-paren: i was on the road last days, after updating my world let's see what is with greeters <muradm>is there any news on 56688 and 56689? <KarlJoad>podiki[m]: That is an impressively obscure bug. I'll try to reproduce later after a reboot. <podiki[m]>well not obscure if your mouse policy is click and you like to watch a video everywhere :-P <podiki[m]>of course thought it was one of my modules, other random settings, never guessed mouse-policy <podiki[m]>muradm: by news do you mean someone reviewing/committing? since it has only been a few days and is the weekend, think you'll have to wait a while (plus with the mumi frontend down there may be more pressing matters) <muradm>unmatched-paren: could you paste upstream link to tuigreet you are dealing with? <unmatched-paren>once i've packaged rust-axum, i'll still have: rust-poem, rust-rocket, rust-salvo, and rust-warp to deal with, which are all web frameworks <unmatched-paren>muradm: Well, it's a dependency of tuigreet that's causing all this: rust-rust-embed <muradm>podiki[m]: yes, that what i was meaning.. then should be back in year i suppose... :D <podiki[m]>muradm: haha hopefully not! I think the usual procedure is to send a ping or ask around after 1 or 2 weeks if there's no indication <unmatched-paren>it also depends on rust-actix-web, but we already have that fortunately <podiki[m]>or when there's people about here that can review/commit to ask them when you haven't heard anything <muradm>podiki[m]: last time it took 10 months for seatd/greetd make to commit :D any way i'm done on my part at least <muradm>just stopping to continue working further <podiki[m]>sometimes it takes a while, but I know you sometimes need to try to get some attention before it gets lost in the deluge <KarlJoad>podiki[m]: Did you have a chance to look at that cycle issue I was having? I don't know how Guix is finding the cycle and I do not know how to query Guix to find it. <podiki[m]>I would go with trying that phase after 'unpack first, since that should be before any other build steps happen (and where I would normally do a patch) <podiki[m]>KarlJoad: what bug are you trying to fix? what is the exact change you want in the end? <KarlJoad>I am doing after 'unpack. The phase ordering is: unpack -> fix-tests -> patch-usr-bin-file -> patch-source-shebangs -> module-dir-point-to-store -> copy-source. All of which succeed. <KarlJoad>I want to be able to install Stumpwm's contrib modules into the store and point my running instance to it. <KarlJoad>In the end, *module-dir* should point to a directory in the store to find modules. <podiki[m]>you mean besides the ones that are already packaged? <unmatched-paren>obviously i'm not the best person to be reviewing patches, due to my inexperience :) <KarlJoad>podiki[m]: I know they are packaged, but I don't think Stump picks them up because *module-dir* gets set to /tmp/.stumpwm.d/modules during build time. <podiki[m]>and you don't want to set-module-dir but have it by default point somewhere? (the problem is that stumpwm-contrib is not needed for stumpwm, so at build time you don't have stumpwm-contrib by default) <podiki[m]>if I'm understanding, you want stumpwm-contrib to be an input for stumpwm, then patch module-dir to point to the store path of stumpwm-contrib <KarlJoad>Yep! That's exactly what I am doing! This is a custom package in my channel, so only I will use it, probably. <KarlJoad>Where the store path of stumpwm-contrib could be a union-build of all the contrib modules I want. <podiki[m]>unmatched-paren: stumpwm has a variable you can set already, in user config <podiki[m]>why not just the full stumpwm-contrib source? <podiki[m]>you don't need to build it I don't think, just need the source <unmatched-paren>podiki[m]: I mean having a native-search-path specified for the packae <podiki[m]>unmatched-paren: I don't think stump uses any env for this, but within the lisp code <KarlJoad>Either or, I'm not sure yet. How the contrib modules are put into the store is not as important right now. <podiki[m]>unmatched-paren: otherwise I would say it would use an XDG dir would be better (maybe it does somewhere, haven't checked) <podiki[m]>I don't think there's a need to complicate it like that, it should use what is available already <podiki[m]>these would be in share/... or lib/.. anyway <unmatched-paren>having every stumpwm module package as an input for stumpwm doesn't sound ideal thoug <podiki[m]>KarlJoad: what I'm saying is that there is already stumpwm-contrib, you add that as input and do your subsitute* to do module-dir to #$(this-package-input "stumpwm-contrib") or similar <KarlJoad>That should work. Seems like exactly what I want. <podiki[m]>ah, but stumpwm-contrib has stumpwm as inputs, I see what you were hitting <unmatched-paren>examples: GUIX_PYTHONPATH, GUIX_LOCPATH, GUIX_GTK{2,3,4}_PATH, GUIX_TRYTOND_MODULES_PATH, GUIX_KF5INIT_LIB_PATH <podiki[m]>yes, I know, but doubt it'll be needed here, and is for one package <KarlJoad>I have redefined some of the contrib modules I want to use a copy-build-system. So maybe that will work... <unmatched-paren>okay then. though how would other packages that provide stump modules be handled? you surely couldn't just add every stumpwm-* to the inputs of stumpwm? <podiki[m]>it is like extras a user might want in their configuration that are loaded at runtime <KarlJoad>Stump runs completely fine without these modules. <podiki[m]>anyway, KarlJoad why don't you want to just set the module-dir in your config? <KarlJoad>It is the expected way, but if I use the contrib modules in the store, then the directory could disappear with a GC. If this becomes impossible to do, then I will resort to that. <unmatched-paren>But is stumpwm-contrib one of several extension module packages available? Or is it de facto the only one available? <podiki[m]>why would it disppear if you installed the module? <podiki[m]>stumpwm-contrib is the full source of all the modules, only some are made as separate packages inheriting from that <podiki[m]>perhaps you want to make stumpwm-contrib installable as is, so one could have the full set rather than just picking and choosing <podiki[m]>in fact, not sure why it was done that way, probably that is the better change <podiki[m]>otherwise I think you can get around the circular dependency by just using the source of stumpwm-contrib (you don't need to compile it anyway for stump to use) <KarlJoad>You cannot install the stumpwm-contrib package because it is not `define-public`. The modules would be installed through guix system. <KarlJoad>So a GC may change the path to the modules, that my config is not aware of. <podiki[m]>gc doesn't remove or change anything that is installed, btw <podiki[m]>I think you should be thinking in terms of changing the guix packaging, if this will be useful <podiki[m]>either we make packages for all the different contrib modules, or I think should have the full set available as one package (could be source only, that would work for stump anyway I believe) <KarlJoad>Fair enough, but one step at a time. I want to figure out if what I want is even possible and usable first. <podiki[m]>I think you are making it more complicated by trying to work around the current packaging <podiki[m]>better to define what it is you want that should be possible from guix, and then go from there <podiki[m]>if it is too "personal" and particular setup, then maybe not for upstream guix, but sounds useful to me to have all the contrib modules available, one way or another <KarlJoad>Good point. But @@ will make it possible to at least test what I want. <KarlJoad>When using `(inputs (append (list (@@ (gnu packages wm) stumpwm-contrib)) (package-inputs stumpwm)))`, I get an error saying `package `stumpwm@22.05' has an invalid input: ("_" ("sbcl-alexandria"`. Am I missing an unquote or something? <podiki[m]>i'm not sure, hard to parse the one line here ***daviid` is now known as daviid
<unmatched-paren>(cons `("stumpwm-contrib" . ,(@@ (gnu packages wm) stumpwm-contrib)) (package-inputs stumpwm)) <podiki[m]>btw, the other thing to do it seems you want is to patch *module-dir* in stumpwm to use XDG_DATA_DIRS with added "common-lisp/sbcl/" to the end; that is where modules are installed in guix in a more robust way to find them <KarlJoad>unmatched-paren: That worked. Thanks! Now to figure out why stumpwm-contrib does not build. <podiki[m]>so yeah, I would say that (xdg_data_dirs) is a good guix patch for stumpwm so that it can use guix installed modules; the other issue is getting all the contrib modules <podiki[m]>KarlJoad: because it is a collection of different modules that need different builds it seems; just need the package-source I think <KarlJoad>podiki[m]: Perhaps I will get around to patching stumpwm-contrib to make it available soon. <podiki[m]>anyway, I think that's it for me for now, but i would recommend the xdg_data_dirs patch as certainly what we want for things to work properly first <podiki[m]>as for all the contrib modules, a source only package (public) would do the trick <bullethead>latest up, pulseaudio needs work as does bluetooth, other than that everything relevant <podiki[m]>so you don't have to build it, since you are only using the source *podiki[m] off for now, good luck <KarlJoad>Everything built and the path is correct in the copied source file. So I think we got it. <muradm>unmatched-paren: tuigreet looks like really mess :) while it says minimalistic (face palm) <unmatched-paren>Yeah, I now have to package the latest version of rust-rand, apparently :) <unmatched-paren>Do you think I should just give up on it? I'm seriously considering that option. <muradm>i doubt that it feasible to support it this way <muradm>screenshot leads to thinking that it is ncurses like which it should be <muradm>but implementation is total mess <muradm>unmatched-paren: i'm giving up :) better to rewrite it i guess :D <muradm>some dependencies even has wierd licenses <muradm>unmatched-paren: let's write minimalist ncurses like :D <muradm>will be cheaper i suppose for porting and for inodes :D <unmatched-paren>`guix pull --use-patch=PATCH`, where PATCH could be a debbugs bug number, mailbox containing a patchset, or .patch file <bullethead>is there anything I can use instead of arp-scan? anything for guix like that? <muradm>bullethead: guix install arp-scan <muradm>bullethead: guix package --search=arp-scan <the_tubular>There's a lot more to talk "Security Wise" than those few points ... I feel that's just a classical distro review that reviews the wallpaper... <nckx>Seems like the usual ‘do these distro's default settings match my arbitrary personal tastes, or is it BAD??’ nonsense dipped in ‘did I mention I'm a CyBeRsEcUrItY PrOfEsIoNaL so you're not allowed to laugh why are you laughing stop laughing you're not allowe—’ sauce. <nckx>Speaking of updates, respect to lfam for bumping linux-libre. My laptop has been deblobbing for *hours* so far. <the_tubular>Well I mean, the default they suggest aren't bad recommendations, it's just very simplistic way of looking at it. <Gooberpatrol66>do I ever need to run guix package --delete-generations or guix gc as root if i don't have any packages installed as root? <nckx>No, in the sense of ‘regular’ gc. Some (e.g., repair) options require root. <Gooberpatrol66>if i run guix system reconfigure as root, and then run guix gc as non-root, will it still clean up garbage from old system generations? <nckx>Depends on how you define ‘garbage’. <nckx>It will not make live roots dead. <nckx>I.e., *turn them* into garbage. <nckx>If you use ‘sudo guix system delete-generations’, a unprivileged ‘guix gc’ will certainly clean up the corpses. <formbi>I'm trying to package a program which uses CMake <formbi>and it tries to install some stuff to /gnu/store/…-dbus-1.12.2/share/dbus-1/system.d <formbi>how to change the location to the package's own directory? <nckx>Probably -DSYSTEMDIR_OR_WHATEVER=… <nckx>Depends entirely on the CMakeLists.txt. <nckx>Which programme is this? <nckx>formbi: Could you share your current package? <formbi>wait a sec, I think I found where it defines the dbus thing <nckx>Prolly src/helper/CMakeLists.txt <nckx>I don't want to interrupt your research, but I have to go, so I'll just leave ‘#:configure-flags #~(list "-DINSTALL_DBUS_FILES_IN_PREFIX=ON")’ here as what I would have recommended otherwise. ***ChanServ sets mode: +o nckx
***ChanServ sets mode: -o nckx
<formbi>not that you're interrupting, I just don't wanna bother people too much <formbi>nckx: it did work, now the same thing about polkit xD <podiki[m]>Oh hey actually I have a package of corectrl <podiki[m]>formbi: feel free to use whatever is helpful, and can help you sort it out to make it ready for guix proper, I just never got around to it <formbi>podiki[m]: I have this: I have this <podiki[m]>and it builds/works so far? I had a lot more inputs (some optional), and looks like a few tools would need absolute (store) paths, rather than wrap-program preferrably <formbi>because it tries to install the polkit stuff where it shouldn't <podiki[m]>and instead of pciutils-no-zlib use hwdata:pci probably <formbi>the dbus thing seems to be dealt with <formbi> file INSTALL cannot copy file "…/src/helper/org.corectrl.helperkiller.policy" to "…-polkit-0.120/share/polkit-1/actions/org.corectrl.helperkiller.policy": <formbi>podiki[m]: what does the uncompressed pci-ids do? <podiki[m]>corectrl wants plain uncompressed files for pci info (as do other programs), that's all <formbi>the polkit package path appears like out of nowhere <formbi>I can't seem to find any mention before the src/helper/cmake_install.cmake file <podiki[m]>let me build the latest with my package def... <formbi>yours doesn't have anything about polkit <podiki[m]>e.g. share/polkit-1/actions/org.corectrl.helper.policy <formbi>I do have polkit as in put as well <antipode>Is there any update on unsticking ci.guix.gnu.org? <ogey>Hello, I am having trouble building python fontpens while doing a full system <ogey> update with guix system reconfigure. When I look at the build log for <ogey> the failed package (pythonfontpens-0.2.4), it says that it failed the <ogey> estimated quadratic curve length test. It says the expected result was <ogey> 107.70329614269009. The result I got was 107.70329614269008. This seems <ogey> like it could be a floating point error to me. Is there anything I can <ogey> do to get my system to upgrade? <antipode>Also, any ideas on 'how far' antioxidant should go before considering it sufficient? E.g., is support for compiling examples and benchmarks and running stand-alone tests needed? (TBC: often there are a lot of non-stand-alone tests, which are already compiled and run) <ogey>ok It is good to know that it is already reported. I use x86_64. <podiki[m]>antipode: still the weekend, likely need to wait until later in the week <antipode>I assume you can work-around it by removing the python-fontpens or its relevant dependent from the profile. <antipode>If you didn't add that or the font manually, I would guess it's pulled in by some graphical environment <antipode>Alternatively, if it doesn't cause a world-rebuild, someone could replace python-fontpens with python-fontpens-bootstrap as a temporary work-around. <antipode>ogey: It consistently passes over here ... <antipode>ogey: does "guix build -e '(@@ (gnu packages fontutils) python-fontpens)' --cores=1 --check --system=x86_64-linux" pass or fail for you? <antipode>(Testing if parallelism is somehow relevant) <ogey>I will check if it works. 