IRC channel logs
2022-12-22.log
back to list of logs
<nckx>I got carried away searching the archives but came up dry. <mirai>nckx: about my last reply, I'm not sure if its already the case <mirai>does a system reconfigure "regenerate" file-system- shepherd services? <nckx>mirai: It's the case in a suboptimal way: the service *is* created, but it's always ‘started’ if my system is to be believed. <nckx>I have /boot (mount? #f), /boot is not mounted, but file-system-/boot is ‘started’. <nckx>mirai: I believe that it should, yes. <mirai>I thought that I didn't see any "new" file-system- services after a reconfigure but after rebooting and doing a herd status to "confirm" this it appears now <nckx>I'd do more testing to give better answers but can't afford to at this moment. <nckx>lechner: ‘in repository maintenance.’ — it's not obvious, but maintenance here is the name of the repository. <attila_lendvai>i'm first trying to use guix deloy, but deep into the process it dies for me consistently with ";;; [2022/12/21 21:48:56.877786, 0] [GSSH ERROR] Channel opening failure: channel 66 error (2) open failed: #<input-output: channel (closed) 7f5d2d8c9660>" <lechner>which channels did you subscribe to, please? <attila_lendvai>lechner, guix, guix-crypto, and that channel we don't talk about <attila_lendvai>although, only the guix channel is needed on the server, but the other two are pulled into my user <lechner>okay, i use the first and the last, and have never seen the error. that leaves guix-crypto. do they use an obscure or extra secure SSH algorithm? <attila_lendvai>lechner, guix-crypto is my channel, it's nothing special, just a bunch of packages and some services. <lechner>have you tried to restart your daemon with sudo herd restart guix-daemon? <attila_lendvai>lechner, restarted on both machines, but the behavior is the same <attila_lendvai>lechner, the machine only has 1GB, but there's plenty of free ram when it happens <lechner>also, you need free disk space on the source <attila_lendvai>there's plenty on both machines. swap didn't change anything and remained empty/unused. <attila_lendvai>lechner, oh, that guix issue looks very much like mine! lemme turn off my ssh config... <attila_lendvai>oh! i have commented out the (identity ...) from my config and now it worked! <attila_lendvai>lechner, yeah, it's a whole new world of managing servers! looking forward to it! :) <lechner>ACTION suggests a small pitfall pointer in the manual <Kolev>Guix does not have CHIRP for ham radio. <jackhill>Kolev: we used to have it, but it's written in an unsupporeded programming language (python2) that we removed. I know there was some work on porting CHIRP to python3, but I don't think that's complete. IN the meantime, maybe guix time-machine can help you muddle through <Guest30>Kolev: you can also take a look at the `guix-past` channel [1], which retains old packages that have been dropped from the mainline distribution (including python 2) <oriansj>is there any reason why vrms isn't packaged yet? <Guest30>oriansj: isn't vrms debian-specific? <GNUtoo>oriansj: note that vrms is known to give bogus results <Guest30>i feel like there was a license-checker package patch making its way through the mailing list the other day though, can't seem to find it now. anyone know what it is? <Guest30>to be clear, the upstream there is the custom implementation `vrms-arch` , which is a rewrite in python vs the perl scripts used in debian <Guest30>neither of which do much for mainline guix, as they either 1. check against a list of "bad" packages (in debian's case), or 2. check against a list of "bad" licenses. For guix upstream this will essentially always be empty in either case <oriansj>well ideally yes but people do make custom channels and it should be checking those too <Guest30>good point, in those cases it would probably be cool to have a deeper license checker (ie, crawling source code for license info) <lechner>sneek: later tell attila_lendvai: now i have the same problem! <lechner>i think bug 56709 may require some higher-level attention. <janneke>civodul: there is a tweet on birdsite that mentions a move to an unidentified place somewhere in the fediverse? <rekado>janneke: we don’t have an account in the fediverse yet <rekado>but we’re no longer using twitter <guixuser>Hi all, I'm trying to write a guix code that will generate images for pinephone pro. Can anyone share the config .scm file if anyone has done it? Thanks. <guixuser>rekado thanks. but for pinebook i got it. <guixuser>rekado I have one more question. You wrote for pine64. What command are you running it with? <guixuser>I don't quite understand the difference for system and target parameters. <rekado>system is for native builds; target is for cross-compilation. <rekado>this is not my configuration, but I build my system images natively (directly on the target machine) <guixuser>So if I'm going to create the image on a different machine, I need to use target? <Kolev>jackhill: I thought Guix was good at supporting old software. Why not package it? <Kolev>jackhill: The official package is a Flatpak. I guess I could use it. <rekado>Kolev: maintaining a large number of Python 2 packages is a serious burden. We have some in the Guix Past channel. <rekado>it’s not something we want to carry in the official Guix repo. <oriansj>well yes Guix is very good at supporting *ALL* software; but the question about where it is packaged is more about who is responsible for maintaining it. And I do wish the various guix channels were more easy to discover; then the problem would be bob runs this channel which contains x,y,z and if you want y, you just need to include bob's channel. <rekado>the list there is not meant to be a list of all channels. It’s only channels maintained by members of the Guix HPC effort. <mrvdb>does anyone have a manifest for working with qmk firmware under guix? or better yet, working on packaging qmk? <oriansj>agreed, I just don't know of a good list of all channels. <rekado>I guess nonguix could host a list of all channels. <lechner>rekado / Hi, is there a way to link store items to the channels they came from? <rekado>no, we don’t record provenance information in store outputs <rekado>the hash doesn’t tell you where something came from <lechner>i thought it uniquely identifies the inputs <rekado>sure, but none of that tells you where something came from <lechner>what if someone kept track of additional information? <rekado>do you have something specific in mind? Because I can’t guess. <lechner>well, if someone were to keep track of all inputs and where they came from, could one figure out (by permutating, if needed) how the hash came about? <lechner>also using the known prerequisites for a store item <mekeor[m]>lechner: why do you wanna know where a store item came from? <lechner>so i can tell people where to get it <oriansj>lechner: you'd also need to store what was used to build it as well <rpana>Don't get why the files derivation fails to build <rekado>the second URL is the same as the first <rpana>I am sorry for that, I didn't realize <rekado>try “guix build /gnu/store/4mvffj172cmvs0rkrijmnvyfg5r9hdi1-files.drv” to see the errors as they happen <rekado>or zcat /var/log/guix/drvs/4m/vffj172cmvs0rkrijmnvyfg5r9hdi1-files.drv.gz <rekado>no idea what’s wrong, but we can check <rekado>open /gnu/store/4mvffj172cmvs0rkrijmnvyfg5r9hdi1-files.drv and look for “…-builder” <rekado>it’s the build script that is failing here on “symlink” <civodul>and i'm stuck at: "Then relabel the file system with restorecon or by a different mechanism provided by your system." <rekado>relabel means to record the context for all files according to the new policy <rekado>you can use restorecon to force relabel all files <civodul>so we tried "restorecon -vR /gnu", as written further down <civodul>ah wait, does guix-install.sh set a service that sets /gnu/store r-o? <rekado>when you use systemd it installs the gnu-store.mount service <rekado>the SELinux-Support thing is ancient, though <rekado>I think it hasn’t been updated in years <rekado>so there’s a really good chance that the policy is outdated with respect to the base policy provided by the host system <rekado>it used to work for Fedora … 20? <mirai>what do the "-- MARK --" lines under /var/log/messages mean? <civodul>rekado: it's Rocky Linux (kinda like CentOS) <civodul>mirai: syslogd prints that every 20 mn to show its still alive <civodul>rekado: so now we can spawn guix-daemon by hand, but "systemctl start guix-daemon" still fails to start it <civodul>i'm not sure where to find SELinux debugging info <ardumont>jsyk, a bit of a report of sort, i've evolved the guix index from extension to a guix script <ardumont>and i've evolved the schema to version 3 to deal with outputs <ardumont>(and the migration thingy does its job according to what i said ;) <ardumont>on my tryouts, i don't have that many outputs though <ardumont>but the git send email does sensible outputs as you mentioned early on in the thread ;) <ardumont>git@2.38.1:gui /gnu/store/1bvxjpyfl47zvyd6wjmf4z907niki8s7-git-2.38.1-send-email/libexec/git-core/git-send-email <ardumont>git@2.36.1:send-email /gnu/store/xsj89hs359iblyxxi74pw6pyprdfbm5m-git-2.36.1-send-email/libexec/git-core/git-send-email <ardumont>now, my next steps would be to understand how to unit tests my stuff ;) <ecbrown>mekeor[m]: i am unable to get in from emacs-debbugs and website seems down <futurile>happy holidays Guix'ers - congrats all on 1.4.0! <futurile>(for those that are taking / on holiday ofc) <rekado>civodul: there’s an audit log, and for some reason you probably won’t find “guix-daemon” in it but just “x-daemon” <rekado>do you see anything of interest in /var/log/audit/ ? <rekado>you can also use sealert to get more info <rekado>you should be able to find some “denied” messages for x-daemon or similar in /var/log/audit; and that would tell you what permissions or context transitions would need to be added to the policy <civodul>rekado: so we ended up *cough* disabling SELinux <rekado>I wish I had a test system where I could play with this to fix the policy <rekado>*everyone* so far ended up disabling SELinux instead of adding the missing bits. <civodul>i must say i don't really want to know about SELinux, and disabling it was an acceptable option in this case <rekado>maybe I’ll get me a Rocky VM and work on it there <rekado>yeah, it’s not a graet thing to know about. <civodul>the sentence "Then relabel the file system [...]" is kinda elliptic <civodul>you need to be familiar with SELinux <rekado>the section was indeed intended for those who are familiar with SELinux <rekado>nobody else would install a third party policy <rekado>that’s usually done through your system package manager <rekado>I’m not even sure it’s a good idea to distribute a policy file <rekado>this policy file makes assumptions about a base policy <rekado>these assumptions were valid many Fedora versions ago. <rekado>I don’t know if they are still valid. <rekado>on a different kind of system with a different base policy this might not work at all. <rekado>we assume that a whole bunch of types have already been defined <rekado>aside from Fedora/RHEL clones are there any other distros that use SELinux? <efraim>that reminds me, I still need to upstream lizardfs <efraim>on the other hand I have a comment about a bug report for compatability with glibc-2.28, so maybe I should see if it ever gets another update first <rekado>efraim: I’m now building kaleido with the latest ungoogled-chromium. Perhaps there’s no need to stick with an old version after all. <efraim>I don't even remember what it was a dependency for at the time <efraim>"of course! if the browser is in your dependency graph you can't possibly miss anything!" <rekado>it kinda makes me mad, to be honest <rekado>you can’t even build a minimal browser (disabling sound or the GUI, for example). Just the whole thing. And then you use a tiny fraction of it as a wrapper around librsvg. <rekado>it’s a plotly / rstudio thing, so sadly it will get much more attention than it deserves. <Kolev>What's wrong with shipping Python 2, just to get CHIRP to work? <rekado>Kolev: Python 2 still exists in Guix. <rekado>but we won’t add more python2 variants of Python packages. <Kolev>Guix excels at shipping out of date software alongside recent software. CHIRP should be able to be packaged. <Kolev>Of course I can always Flatpak it. <singpolyma>Kolev: you also don't need anything to be in guix upstream to use it, which is very nice and useful <efraim>With python 2 past end of life we're not adding new python 2 packages into guix proper <Kolev>singpolyma: So CHIRP is being maintained in an external channel? <singpolyma>Kolev: I have no idea what that is. But you don't even need a channel if you don't want. Just a text file <jackhill>ACTION tries out `guix time-machine --commit=a53d1098dc6b70c721fddc619de9c41106503d2b -- shell chirp` <jackhill>a53d1 is the commit before CHIRP was removed. <jackhill>I wonder if it would work in touthon (not packages, not even sure if touthon is maintained any more). Best long term solution I think would be to modernize CHIRP <singpolyma>jackhill: maybe, but luckily with tools like guix you don't really need to if you just wanna use stuff, which is nice <jackhill>singpolyma: indeed. Mostly, I'd like it modernized for other reasons too (like using libadwatia for use with on-the-go computers 😁) <jlicht>getting our node-build-system to work /w the latest Node.js LTS version turned out to be a bit more of a chore than I'd hoped XD <pjalsDanielv[m]>hi, how do i make guix use a seperate /boot partition which is encrypted using luks1 (not efi, i use legacy boot)? i've tried to look around in the manual and found nothing. i specifically want to do this to use luks2 on / but grub doesn't like that for some reason <pjalsDanielv[m]>i've already tried specifying /boot in file-systems but that didn't help for some reason <lechner>pjalsDanielv[m] / Hi, often the boot partition is the one folks do not encrypt <pjalsDanielv[m]>iirc grub fully supports luks1, but luks2 support is janky when i tried it <nckx>Also, separate /boot requires writing your own script to copy over files. It's not supported by Guix proper (yet). <nckx>apteryx: Remind me why you wanted to avoid argument parsing in guix-install.sh? For ‘--uninstall’, we'll need it anyway. <jlicht>ACTION would listen to a nckx and lechner podcast :) <jackhill>Kolev: I can confirm that my time-machine command above works. You can also run other guix commands in the time-machine as well in addition to shell (like perhaps package -p chirp -i chirp) <apteryx>I also can never remember which to use between GNU getopt (which lives in util-linux) vs bash getopt ;-). It's the former. <efraim>might need to rework the minimalism of qemu-minimal <apteryx>that works too, but I like short/long options <nckx>If we ever truly need ‘--this=stuff --who even -omgno’ parsing, we can use getopt. <nckx>apteryx: What's wrong with built-in bash getopts? <jonsger>ACTION signed the Guix Days 2023 list :) <efraim>I think ipxe uses a BUILD_TIMESTAMP <efraim>nvm I take it back, it's supposed to be there <apteryx>very much! and #bash has nice experts to complement it <PotentialUser-57>Hello guys. I am running into a problem when doing guix system reconfigure, and the description is that the file used "does not return an operating system or an image". Does anyone know the reason for this to happen? <apteryx>I think traditionally there were a bunch of 'getopt' that differed in behavior <apteryx>but that's not much a problem nowadays on GNU/Linux systems <PotentialUser-57>I have been also experimenting with setting up the system as modules (base config + system config that uses the base configuration) but when running guix system reconfigure I was always getting the following error: ice-9/boot-9.scm:3330:6: In procedure resolve-interface: <PotentialUser-57>no code for module (base) Tried with sudo -E option as well, but it didn't work. My /etc/guix does not contain any configuraiton files, could that be a problem? <nckx>PotentialUser-57: Is (operating-system …) the last form in the file? Or, alternatively, (define my-os (operating-system …)) (other) (stuff) my-os? Or, alternatively, just share your file :) <nckx>You need to explicitly add any module load paths if you aren't doing so yet. Either with Guix's ‘-L’ CLI option, or using something like ‘(add-to-load-path (dirname (current-filename)))’ at the top of your /etc/guix/system.scm. <nckx>I've noticed that the latter can make error messages go weird, but when it works, it works. <mekeor[m]>rostick: add "base-operating-system" at the end of your file <mekeor[m]>rostick: your system.scm does not need to define an OS, but rather it has to evaluaate to an OS <nckx>rostick: You can also simply remove the outer (define base-operating-system …) wrapper if you're not re-using it anywhere. (define foo 5) does not evaluate to 5. <nckx>mekeor[m]: 9 o'clock in the evening. <rostick>nckx indeed removing (define base-operating-system ) did the trick, but now I am getting another error: ice-9/eval.scm:223:20: In procedure proc: <rostick>error: mapped-devices: unbound variable <rostick>hint: Did you forget a `use-modules' form? <rostick>Apologies in advance for silly questions, I am just starting to use guix and have little knowledge of Guile Scheme <nckx>rostick: You wrote (or copy-pasted? :) ‘(dependencies mapped-devices)’, but no actual mapped-devices field. If you don't have any mapped devices, remove that dependencies field. <rostick>I'll be honest with you, I copy pasted the config and tried to tweak it:) <rostick>Now I am not sure if it is a good idea to try and run this system reconfigure, as I feel it may break things and I will have to roll-back from grub <nckx>rostick: I won't push you to do anything you're not comfortable with, but is that so bad? (The answer depends on where you got your currently running system from, I guess.) <rostick>The currently running system configuration is generated from the official system installer, and I use it on a secondary laptop for such experiments. My goal is to create a base configuration that can be appended for further use on my other machines and I find that the stock configuration does not serve this purpose very well, so I am looking at <rostick>configs of other people to determine a way to do it <msgilligan[m]>Hello, I'm trying to install and use openjdk-18 and maven with guix on Debian bullseye and I have a question... <nckx>What do you mean by ‘meant to be overridden’? That's true for ‘guix system vm’ only. <msgilligan[m]>... when I install openjdk@18.0.2 (or some other versions that I tried) I get a working java but I can't find a javac executable. Is there an additional step to install the javac compiler? What am I missing? Is there a place I can go for documentation specific to OpenJDK on Guix? <rostick>nckx I didn't mean that it's supposed to be ovverriden, but rather that the "base" module is used in per-machine configurations. Although I don't quite understand how the modules work yet, so will refer to the user manual for more details <nckx>msgilligan[m]: javac is in the :jdk output. ‘guix install [or whatever] openjdk:jdk’. <nckx>You can list outputs with ‘guix show PACKAGE’, but there's no way (yet!) to search ‘which file/command is in which output?’. You just need to know. <nckx>This will improve in time. <nckx>Some things are well-documented. Others are… not. <nckx>If you want to re-use this definition you'll have to restore the define-public eventually, but as mekeor[m] suggested, making that work is as easy as adding ‘base-operating-system’, or any other valid variable, as the last line of the file passed to ‘guix system …’. <msgilligan[m]>nckx: Thanks! `guix install openjdk:jdk` worked! (I had previously tried `guix install openjdk-jdk`) <msgilligan[m]>I'm new to Guix, but hope to make some (at least minor) contributions. Is there documentation somewhere I could send a PR to for this issue? <rekado>efraim: after a few hours of building chromium it finally started building kaleido sources — and immediately failed :) <rostick>nckx I tried adding it (base-operating-system) as the last line of the config file, but it didn't change anything <nckx>rostick: Change anything from where? I'm not sure which error you're currently debugging. <nckx>‘(define base-operating-system…) \n base-operating-system’ addresses the problem that your file did ‘not return an operating system or an image’. Nothing more. <rostick>nckx this time it is: error: base-operating-system: unbound variable <rostick>hint: Did you forget a `use-modules' form? <nckx>Did you re-add the (define base-operating-system …) around your o-s as well? You need both. <msgilligan[m]>nckx: I guess what I would like to see (and searched for) is a "how to" on installing Java and building Java apps with Guix. I currently don't know Guix well enough to contribute to the "file search" issue. Is there a place where I could submit an OpenJDK how to? <nckx>rostick: I shouldn't have distracted you with the ‘define’ business at this stage. It's not that important yet, only when you want to make multiple variants later. <nckx>msgilligan[m]: Yes! You could add it to the cookbook, which is meant for targeted goals/how-tos. <https://guix.gnu.org/en/cookbook/en/guix-cookbook.html>. It's also in the Guix git repository, as a Texinfo source file (in doc/). But if you're not ready to edit Texinfo (it's just another text mark-up, nothing too scary), you can also draft a text and submit it to guix-devel at gnu dot org for review. <nckx>elevenkb: The short answer is that it's part of GCC (gcc:lib). I don't know the long answer to ‘what's the (most) correct way to use it’, though. <msgilligan[m]>nckx: Thanks! I'll take a look and see if I can figure out Texinfo. <nckx>msgilligan[m]: Thank you! <rostick>nckx thank you for your help, I will continue to figure this out tomorrow <nckx>OK! If you can't, paste your current configuration again. It helps. <HexMachina>rekado: not that it necessarily matters for Guix, but Android uses SELinux extensively, they have a very hardened policy <rekado>HexMachina: right, I meant GNU+Linux distributions.