IRC channel logs
2023-06-29.log
back to list of logs
<Kolev>My laptop gets an IP address from the bridge but my ATA does not. I've rebooted the ATA and the ethernet bridge. <sevan>hi, in guix/tree/master/gnu/system/images I see a file for the pinebook pro, and one for the pine64. Does the pine64 file suit the original pinebook? (white laptop) <vagrantc>sevan: you'll need to use a different u-boot <sneek>vagrantc, you have 1 message! <sevan>vagrantc: so the pine64 config applies, just need the correct u-boot? <sevan>at a glance seems so as the use the generic arm64 kernel <sevan>setting up a serial port threw me. <vagrantc>yeah, the kernel is fine ... but you probably want the correct boot firmware ... <vagrantc>it is close enough pine64 *might* just work, but you might end up with some ugly quirks, worst case the wrong voltages going the wrong places! <vagrantc>oh, it will also load the wrong device-tree, so you will not get output on the LCD, for example <atka>hi guix, I have a simple mcron job that runs a bash script that uses curl. I have curl and nss-certs installed system wide, I can run the script as my user without issue. when telling mcron to run the script curl complains about lack of certificates, telling mcron to run the script as my user doesn't work either. the script runs without error if I schedule mcron to run 'guix shell curl nss-certs -- <atka>any ideas why this is? how can I verify what user mcron is running the script as? <frog>probably because it isn't loading the system-wide profile before loading mcron, causing the environment variable the for certificate path to be missing. <frog>manually load it by putting "source /etc/profile" at the top of the bash script to test. <atka>frog: thanks for the tip, I'll try that <atka>frog: ok, adding 'source /etc/profile' to the top of my bash script does work <atka>maybe I'm dense here, I'm not clear on how things are being processed when run via my user directly and mcron running it as my user <atka>is the issue to do with how bash is invoked and where it looks for startup files? <frog>the /etc/profile script loads the default system-wide profile and your user-specific profile. according to the bash documentation, /etc/profile is run automatically for interactive shells. if you run the script manually after logging in, it inherits all the environment variables from the profiles and runs fine. <frog>It seems that mcron as a system services doesn't source the system-wide profile automatically. I guess this is because guix doesn't load anything before starting mcron, and any instances of bash started by mcron to run scripts aren't interactive and therefore don't load /etc/profile. that's my guess. <atka>frog: thanks, makes sense, would you say that sourcing /etc/profile from within the script is an appropriate workaround? less hacky than guix shell for sure <frog>atka: it's not bad. personally, i would write code in the config file to to automatically wrap all of my mcron jobs with a script that sources /etc/profile and then runs the original script. i think that guix not doing this automatically is a bug/oversight. <atka>frog: thanks for your input, I'm a noob, trying to learn and do things the guix way (TM) <adanska>Just bumping this:Hi guys! Just wondering: is there anyway to use ‘keyboard-layout’ in my operating system declaration to declare my keyboard layout on a wayland session like you can with ‘set-xorg-configuration’? i’m trying to use the ctrl:swapcaps option for a gnome wayland session. <atka>guix users on btrfs, what's your subvolume layout like? <lfam>Am I the only one with the impression that the build farm (the Berlin portion) is stuck? <lfam>I don't think I'm using subvolumes for my btrfs Guix system <lfam>Or if I am, I don't have to know about it <atka>I usually like to have /boot /root /home/user on separate subv <jackhill>atka: I do / and each users' home as a separate subv <atka>but with guix dunno if I shuold add /gnu to its own subv <lilyp>I have /home sitting on a separate hard disk if that counts <jackhill>the integration with the guix user records and the home subvolumes isn't the best, but fortunatly I don't add new users very often. My workflow is the create the subvolume, mount it, reconfigure with the user, then copy over the skeleton files and fix up ownership by hand <atka>jackhill: oh yeah, it's been a while since I set it up, I remember manually having to set that up as well <atka>can guix break if you have separate subvolumes but only roll back one of them? <atka>everything important is under /gnu right? <lilyp>if you roll back the subvolume that has /gnu, I think your symlinks in the others will break <jackhill>probably best to keep /var/guix and /gnu in sync. I haven't stress tested anything. There's a sqlite database in /var/guix that's important <atka>yeah, maybe just keep / all together then <jackhill>with Guix though, I don't anticipate having to use the filesystem to roll back configuration changes, just use Guix for that. I use separate subvolumes to break up backups and quotas <atka>yeah, I just want to be ablet to btrfs-send my home somewhere else <atka>and use compression, reflinks, etc <atka>I think i'll just use a subv for / and /home on my laptop install <jackhill>I've been testing bees dedup too. Pretty awesome, just needs a guix service <atka>oh cool, I'll check it out <atka>I'm hoping to get into a fresh install tomorrow and set up dwl-guile, pipewire tomorrow <bdju>I have been wanting to switch to pipewire on guix system. is there documentation on how you get it working? <atka>if you don't copy over the skel files on a new user and use guix home import ~/src/guix-config, will it create everything you need with the guix-defaults #t field? <atka>bdju: I would like to know as well <atka>I've really only used guix in a sever capacity, never set up a desktop environment <atka>I know I don't want to pull desktop-services, I'll have to build it up bit by bit :/ <juliana[m]>sneek: later tell adanska you can use the xorg configuration for you keyboard just fine running wayland with gdm <bdju>yeah I use base-services to avoid GNOME/GDM stuff <atka>bdju: do you use wayland? <atka>hopefully dwl-guile doesn't need much <atka>it has a home service, so maybe it will be easy to get working with minimal dependencies <ngz>cbaines: I pushed a few fixes to "tex-team-next" branch a few hours ago, but the build process seems stuck. Is there something I need to fix on my side, or should I just wait? <sneek>civodul, you have 1 message! <TristanCottam[m]>Does anyone have any idea if there's any work going into updating GNOME Shell? I can't find anything online. <TristanCottam[m]>AwesomeAdam54321: The last commit relating to `gnome-shell` dates back to September 2022. I'm interested in GNOME 44, and would have expected to find a related issue in the issue tracker. How come? <futurile>Doh! I just deleted my own patch because I didn't realise that "./pre-inst-env guix search" was finding the one in my tree heh heh - more coffee! <sughosha>Hi all! I am packaging a rust application which has a git dependency. I packaged the dependency but while building the package is trying to fetch from git and failing. Is it possible to map the git dependency to the packaged one? <cbaines>it looks like the data service started processing the revision many hours ago, but it does take a long time since it has to build some of the tex stuff to build Guix itself <ngz>Well, it may be just me. This branch took me a month of work, yet I'd like it to be built in a few minutes ;) <bovid-19>I am trying to package and install shreddit [http://github.com/andrewbanchich/shreddit]. It requires a newer version of `rust-async-stream' than currently provided. I thought `guix refresh -u rust-async-stream' might help, but I get an error: `guix refresh: error: mkstemp: Read-only file system'. Any ideas how I could fix this? <cbaines>bovid-19, I'd suggest running ./pre-inst-env guix refresh -u rust-async-stream from within a guix.git checkout <bovid-19>No. It's owned by root and rights look like this: `drwxrwxrwt'. <cbaines>I'm unsure what's wrong then, I think guix refresh is having problems creating a temporary file on your system for some reason <bovid-19>I'll probably just try and start with a fresh guix system. Some other stuff also broke a while ago and if there's no obvious way forward, it's probably easier that way. Thanks! <irfus>hi guixers! I'm trying to package torchaudio for guix and having the build fail because it's not fetching git submodules apparently. <irfus>^ that's the module with the package definition <cbaines>irfus, I'd try and work out what it's expecting to do when it says "Initializing submodules" <irfus> cbaines: it seems to be a step in the setup.py <irfus>a step where it runs _fetch_third_party_libraries() <irfus>these packages should probably be packaged separately and inclded as inputs, I'm guessing. But do I then have to patch the source to skip that step as well? <lysgaard[m]>I am a noob trying to make my first guix package. As I develop a lot of Rust code I would like to understand how well the rust ecosystem is supported in guix. My first try is to make a guix package of the rust-opencv bindings. It is only for an exersize, but it is quite valuable, as it touches on a lot of hard topics, like tricky native dependencies, automatic code-generation for C-headers etc. My first try is this package: <lysgaard[m]>The way I understand it, this is because the opencv crate first builds a sub-crate, that generates the C++-Rust bindings from the available opencv headers. This sub-crate has some dependencies that are not listed in the super-crate, and thus cargo-build-system somehow fails. Anyone have pointers on this? <nckx>Wasn't bovid-19's issue that they were 'upgrading' a package in the store, rather than a local checkout? Not using ./pre-inst-env? That's a bit of a sharp edge of that tool to say the least. <nckx>A hint would be a goodfirstpatch™. <Guest28>is it possible to have /gnu/store as a nfs share, so I could have one NFs share for multiple machines to have a huge cache? <podiki[m]>I didn't hear any objections (or affirmations, or anything actually) about the proposed mesa (plus friends) update branch <podiki[m]>I think I'll go ahead and create it then, as the commits are all pretty trivial, the main task is getting it built <apteryx>podiki[m]: sounds good to me; perhaps we could have a graphics-team or something <podiki[m]>yeah, I was trying to figure out the right scope for something like that <apteryx>but that's a bit blurred in scope... I'd like a team with updates that make sense to group together, like mesa, xorg, wayland, etc. <podiki[m]>anyway, if anyone knows any other patches for such a branch let me know; I'll ping guix-devel with an update later <podiki[m]>as of now it is a mesa fix, mesa update, and someone had pointed out harfbuzz was out of date <apteryx>but that's becoming akin to a core-updates branch so perhaps it's best to leave it focused at mesa; that was the original idea I think (at the expense of extra build churn) <podiki[m]>although if things just need version bumps without expected upstream big changes, hopefully they can generally be grouped together <psycotica0>Hey folks! I'm having some trouble packaging something and am looking for some best-practices. Well... maybe slightly less than _best_ practices. This package is a bit weird. It uses the gnu toolchain, but during the configure step it goes out and fetches some tarballs off the web, downloads and extracts them, applies some patches to the unpacked <psycotica0>sub-source that are kept in the main repo, then runs configure on the resulting sub-source. And during build it will build them all together. This is problematic for guix because it involves downloading things during the build, which is a no-no. <psycotica0>So since it doesn't seem like guix allows multiple sources for a single package, I could have a second package that represents the tarball, basically. And that would basically just download the tarball and put it into the store without doing anything to it. And then I could have a relatively minimal patch in the main package that just changes the <psycotica0>tarball download location to be a file:// uri to the place in the guix store where that native-input lives, so it would download from the store and then the rest of the upstream tooling should just work, I think. <psycotica0>So my first question is whether there's an easier way to handle this kind of issue that doesn't involve rewriting large parts of upstream. And the second question would be whether or not there is an easy (source) entry I can use which is "download this file and only this file and just leave it as-is", as in, download the tarball but *don't* unpack <psycotica0>it, and don't do anything else, just put it in the build folder. <vagrantc>psycotica0: i think you can define multiple sources ... but also defining the tarballs as source packages would be possible too <vagrantc>psycotica0: sorry i don't have examples off the top of my head <podiki[m]>tao: what is your desktop environment? i've seen this before when not launching dbus for the window manager (e.g. just using stump or xmonad directly) <tao[m]1>podiki GNOME. I'm using Guix's gnome-desktop-service-type: not sure how I'd launch GNOME with dbus-run-session by modifying the service <podiki[m]>so then gnome should handle dbus already; sorry that was my only idea <podiki[m]>did you restart/relogin after installing the portals? <podiki[m]>i'm not familiar with xdg-dbus-proxy either, sorry <podiki[m]>last idea: if you are running under wayland, you need the wayland portals instead <psycotica0>Hmm, looks like there's a `download-to-store` defined in (guix download). Maybe that does what I want... <tao[m]1>I just threw it in there as a kind of throw everything against the wall and see what sticks. Oh is that xdg-desktop-portal-wlr? <podiki[m]>tao: yeah, -wlr rather than -gtk; again I know nothing in that front :-P <tao[m]1>podiki i will try -wlr but I just switched over to Xorg and get the same error. I'd assume it'd just work over on X11 <podiki[m]>not sure then, may be a more general gnome/dbus/portals thing, maybe search about that in case it is not guix specific, but I don't know <podiki[m]>does echo $XDG_DESKTOP_PORTAL_DIR show you anything? <tao[m]1>podiki /run/current-system/profile/share/xdg-desktop-portal/portals <tao[m]1>In there I have gnome-keyring.portal, gnome-shell.portal, gtk.portal, wlr.portal <podiki[m]>could try dbus-launch to run the flatpak app and see if that helps; otherwise seems like something is awry with dbus; I would think gnome launches and runs dbus already but I don't know the details there <jackhill>hey, I haven't been following the conversation, but lately, I've noticed that pipeware screnshare has stopped working for me in sway, but continues to work in gnome. I haven't had a chance to dig deeper, which is why I haven't reported it, but maybe that sounds similar to your problem? I launch sway with `dbus-run-session sway` <tao[m]1>Yeah this sounds like it might be a bug with how Guix implements the GNOME session? <podiki[m]>tao: that seems to indicate dbus isn't being run or is run in a way that doesn't pick up all the dbus stuff <AwesomeAdam54321>psycotica0: Regarding the easy source entry, (origin ...) is what you're looking for <psycotica0>Right, (origin) appears to be the normal way packages are defined, but they contain a (method), and it seems like the (method url-fetch) extracts the tarball. Do you know the syntax for what I'm trying to accomplish, where it just downloads it and leaves it alone? <psycotica0>Ooh! That's good insight. I'll take a look. Thanks! <podiki[m]>tao: some of that might be expected, would need to compare to a similar system (e.g. I think something is trying to open /run/dbus which doesn't exist and so on) <AwesomeAdam54321>psycotica0: Could you ask the upstream why they patch dependencies? Maybe those patches would be accepted if they sent them to the respective projects <zeropoint>does anybody know what is needed to allow gpg to read smart cards? I just revoked some subkeys for the first time on guix and gpg --card-status is not seeing anything. <podiki[m]>mesa-updates branch created, will make a merge request issue after lunch <podiki[m]>zeropoint: I use the "pcscd-service-type" in my config along with (udev-rules-service 'u2f libfido2 #:groups '("plugdev")) for my yubikey <mirai>apteryx: can you remind me how this VNC GDM issue started? <mirai>did it occur with a system reconfigure ? <vputz>I feel most foolish, but trying to do a simple package expression that downloads a tarbomb in .tar.bz2 format via url-fetch/tarbomb. But that derivation always fails with an error `tar (child): lbzip2: Cannot exec: No such file or directory`. I've tried adding (inputs (list lbzip2)) or (native-inputs (list lbzip2)) to the package, but that <vputz>seems to add it to the outer (consuming) derivation, not the one that's failing (in the (origin) block). How do you url-fetch/tarbomb a bz2? <mirai>vputz: what about bzip2 in native-input <vputz>Same, I'm afraid. So just for reference (I can post a gist somewhere if needed) the package name is micromamba, the download (file-name) in origin is micromamba-1.4.4.tar.bz2, I currently have (inputs (list lbzip2)) and (native-inputs (list lbzip2)). I then have three derivations that come out: profile.drv, micromamba-1.4.4.drv, and <vputz>micromamba-1.4.4.tar.bz2.drv. The error is that the last (...tar.bz2.drv) failed (lbzip2: Cannot exec: No such file or directory). <vputz>So if I grep for bzip2 in those derivations, <vputz>❯ grep -l bzip2 /gnu/store/wxxyvjr57sh19i53q25k7k79i2fnk7f5-profile.drv /gnu/store/g1zynxspw0zia6j1z8zfvdi297q982nk-micromamba-1.4.4.drv /gnu/store/x7vwr01a4k4wlis96vhvv680llk5cj90-micromamba-1.4.4.tar.bz2.drv <vputz>...the "app" derivation has it, but the .tar.bz2 one doesn't. <vputz>(sorry, the grep output there was /gnu/store/g1zynxspw0zia6j1z8zfvdi297q982nk-micromamba-1.4.4.drv, showing that's the derivation that has a bzip2 in it) <sarg>hi guix. It seems that `(delete TYPE)` clause of `modify-services` deletes only the first occurence of the service. Info says: `Such a clause removes all services of the given TYPE from SERVICES.` though. <morte_>Hello everyone, is there a way to install a minimal version of Gnome for the full guix system? <nckx>sarg: Bug if true! Could you report it to bug-guix at gnu dot org with a simple reproducer? <lilyp>morte_: there is no gnome-minimal per se, but you can inherit from gnome and drop the packages you don't want from propagated-inputs <lilyp>in gnome-service-type simply use (gnome my-minimal-gnome) afterwards <Bionicbabelfish>hi all, I'm trying to get `make check-system` to work in order to add some test to a guix PR. I'm getting an error: "guix build: error: service 'term-tty6' provided more than once". Could anyone point me in the right direction? <podiki[m]>sarg and nckx: there was discussion/bug reports recently of deleting services and needing it multiple times, don't have the number handy though <Guest59>can I replace my /boot partition with guix system reconfigure? I am currently using u boot but want to use efi grub <lilyp>Guest59: IIUC Guix ought to install efi grub normally if you put it into your config file <lambdanil>Hi, can somebody tell me what "In procedure abi-check: #<record-type <shepherd-service>>: record ABI mismatch; recompilation needed" means? <lambdanil>it fails to load my custom service and shows this as the error <lilyp>it means you have to make clean-go <Guest59>i am trying to cross build from x64 to aarch64 <mirai>Bionicbabelfish: its a bug in guix atm <mirai>I'm not sure what the test name for it is but you can run specific system tests <mirai>via make check-system TESTS="name-here" <psycotica0>I have a new question. Let's say I want to modify a package (as in, inherit or otherwise transform). So I have a guix.scm in this folder (which does not contain the upstream source) to define the package, and then I have a few files I'd like to replace in the upstream source or patches I'd like to apply to the upstream source. This folder only <psycotica0>contains the new files I'd like to overwrite upstream with. <psycotica0>Is there a good way to get my local files into the package somehow? <psycotica0>Like, I assume at the worst I could read the files and iterate over them in scheme to read their contents into variables, and then I could escape the package definition and inject these contents into a new phase that created new files from the string contents. But that sounds hacky and tedious. Is there an easier way to "copy some local files" into <peterpolidoro>hi. I am upgrading the version of the python-tabulate package from 0.8.9 to 0.9.0. it builds properly and puts the output into /gnu/store/...python-tabulate-0.9.0 However it places inside that directory lib/python3.10/site-packages/tabulate-0.0.0.dist-info. Other python packages that need tabulate as a dependency do not recognize the version as <peterpolidoro>0.9.0, instead they think it is 0.0.0. Is it a flaw in the source code that causes the 0.0.0 version? Is that something I can fix in the package definition? <juliana[m]>yeah so you'd inherit the upstream package definition and override the `source` field with `local-file` or whatever; then override any other fields you need to change. you can still build off of or modify the upstream fields by accessing those fields of the upstream package using `package-<field>` and then modifying the resulting data (usually it's a list of some kind; there are helper procedures for modifying some of the fields, too) <juliana[m]>if you need to change the version you'd do like `(package (inherit <upstream>) (version <new-version>) ...)` <juliana[m]>the source field is just another field, so you can look at inherited packages in the main Guix codebase for examples <psycotica0>Right, but I still _also_ want the upstream source. Right? Like, I'd like to get the upstream source and then copy a few files overtop, or apply a patchfile. So I don't really want to override it, right? <psycotica0>But maybe I'm just unclear on the relationships at work here... <PotentialUser-26>how to do you remove packages using guix home? The specifications->packages (list "x" "y" "z") install's pkgs but how do I go about remove these if I change my mind <ekaitz>PotentialUser-26: reconfigure :) <juliana[m]>PotentialUser-26: you'd remove them from your package defintion then reconfingure. you can delete old generations to remove them from the store then run `gc` to get them off disk if you want <juliana[m]>psycotica0: so you'd inherit them probably do some sort of list modifications on `(package-source <upstream-package>)` <psycotica0>Is it possible for a package to have two sources? Like, both a url-fetch and also a local-file? <psycotica0>Oh! There's in inbuilt `patches` field... Hmm.... <juliana[m]>if you've modified a local definition you'll probably just want to produce patches to change the relevant stuff and apply them at build time. or like if you're removing directories or files, that's what snippets is for. etc. <psycotica0>Right, right. I think the thing I'm struggling with conceptually is just that the build env is different than my local env (the one in which I'm calling `guix build`) <psycotica0>So the part I'm struggling with is making sure my local files are somewhere the builder can see them, for when the build phases are actually processed. <psycotica0>Ok, cool. That sounds like a direction to start in. Thanks! <juliana[m]>and you may well know this, but if you're running guix build you'll probably wanna throw on the -K flag so you can inspect the build directory a failed build <juliana[m]>and if it's building successfully but not the way you want, you can add a phase that throws an error after whatever steps you want to inspect <psycotica0>I think you're going to have to give me an example here ;P <singpolyma>Look in guixrus for the riddim package for example <singpolyma>Anything you can put in origin you can put in input <psycotica0>And then you'd just use the assoc-ref to get the path? <rekado>there seems to be a bug in “guix refresh”. I’m using it for the current mass upgrade of CRAN packages and it seems to sometimes lose its location in the file, causing it to try to edit a package definition outside of the definition context. <rekado>this seems to be related to packages with labeled native inputs