IRC channel logs


back to list of logs

<jackhill>it's shame that getting certs has to tie up port 80. Apache's mod_md looks quite nice
<awb99>what is also missing is a cloud service, a package that modifies harddisk size, and reports to the hoster certain stuff.
<awb99>there seems to be a standard that the other distros use.
<bcr>Can guix-daemon handle the case that an HTTP proxy is used for HTTPS traffic, with the proxy decrypting/reencrypting things? In particular, how can I tell guix-daemon to trust the proxy's certificate?
<singpolyma>jackhill: some way to handle secrets would be nice indeed.
<singpolyma>I ran into that pretty quick with the new setup I'm building
<lilyp>how does one get access to the git?
<muradm>hello guix
<nckx>Hi muradm.
<ardon>Hi guix, is it possible to re-load Emacs packages I've just installed on its standalone profile without leaving the current Emacs session? I think it would take modifying the load-path variable.
<awb99>stupid question: how can I manually trigger a NTP time sync?
<awb99>My system is off by too much.
<awb99>So I have to trigger a manual sync.
<awb99>but dont know how.
<nckx>awb99: Which NTP server are you using?
<awb99>I have no idea.
<awb99>The standard servers that come with desktop-services.
<nckx>ISC NTPd (ntp-service-type). The ‘ntp’ package comes with the deprecated ntpdate command which you can use to jolt your system clock into now: sudo ntpdate -u
<nckx>It will eventually go away (‘soon’, but lucky for you ISC's definition of that is glacial).
<awb99>ISC ? what is this. thanks BTW!
<nckx>Fine creators of the NTP servICE (which I of course mistyped ‘server’ above) you're using. They also make BIND.
*nckx 😴 but not 💤, unfort.
<nckx>However, I'm not sure why the -g option (allow-large-adjustment?, which according to the manual defaults to #t), didn't do the same automatically.
<nckx>Did ntpdate?
<awb99>it did. thanks.
<awb99>but it is bizarre
<awb99>I only have a few microseconds drift.
<awb99>error resolving pool Name or service not known (-2)
<nckx>How off was your clock? If it only a ‘few’ seconds ntpd will try to slowly skew it back to now, so's not to upset running programmes.
<awb99>kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
<nckx>That's normal.
<awb99>my clock was off by 0.3 milliseconds.
<nckx>That's Linux silly way of saying ‘you haven't set your clock this boot’, the ERROR is entirely inappropriate.
<brendyn>I get that alot but never really understood if it mattered
<nckx>It's a very badly designed info message.
<nckx>Oh, so you weren't actually looking at a clock that was 3 hours slow ☺
<awb99>I am going through the logfiles,
<awb99>and try to correct what is not ok.
<awb99>I managed to kill my digital ocean server,
<nckx>awb99: has only A records (which do resolve), are you perhaps on an IPv6-only connection?
<nckx>It's not great that the NTP pool is IPv4-only, but it's (as so many critical Internet things) a volunteer project…
<awb99>sent a few "guix deploy"
<awb99>and now my server is offline
<awb99>and as it looks, there is nothing I can do to debug it really.
<awb99>as the service is off,
<awb99>sshd not available.
<nckx>No VNC, (fake) KVM, or similar console?
<awb99>havent found it yet.
<awb99>I dont know about my IP.
<awb99>I am behind a router,
<awb99>and I have a private IP4 address.
<awb99>not sure how the router is on the outside.
<nckx>Well, unless you're seeing actual wrong times, you probably don't have to care about it anyway. I thought your time was seriously off.
<nckx>0.3ms is fine for NTP.
<awb99>I am on IPv4.
<awb99>the router is.
<nckx>Then I don't understand the ‘name or service unknown’ message unless it was also pasted from early boot logs, before the network or DNS are up.
<nckx>But since this is a VM that may well be moot (I'm not familiar with DO specifically) since the ‘hardware’ clock is emulated anyway, and may well itself be synced already.
<nckx>I have however heard too many DO adverts to believe that they don't have a rescue console ☺
<Guest1626>hello. when running `guix package -m manifest.scm -v3` i see no output/progress no matter the verbosity level (apart from the initial header of what will be installed) - is this intentional? how can i get progress output like when running `guix install ...`?
<nckx>Throwing ‘hello’ into a manifest and running ‘guix package -v3 --no-substitutes -m /tmp/m’ starts to spew build output here.
<nckx>(No, it does not seem positional.)
<lilyp>possibly depends on how much Guix actually does?
<lilyp>also maybe there's not much verbose outputs when fetching substitutes
<nckx>What different output do you see between the two?
<brendyn>running find...sed over the repo seems to have messed up mtimes or something so now make doesnt make everything properly. running guix still has to compile heaps of scm files and says they are newer
<nckx>sed -i on some .scm files shouldn't do anything make doesn't fix. I literally just did that.
<nckx>Have you tried make clean-go && make?
<Guest1626>this is all I see:
<Guest1626>umm ok, how do i do markdown here...
<nckx>Please don't.
<Guest1626>oh ok
<nckx>There's a pastebin in the topic,, please use that.
<nckx>If it's 1-3 lines, here is fine, but plain text please 😉
<Guest1626>Uploaded file:
<Guest1626>oh that was nice, it did it for me when i pasted - living in the future now lol
<nckx>People use all kinds of clients that have all kinds of different features (we didn't know yours until that link showed up), but the messages themselves are plain text. Unicode is as fancy as it gets 🌈
<nckx>I'm a bit confused by that output. There should be at least a bit more. Also, if all of those packages are already in the store, it won't print any output, but then neither would ‘guix build’.
<Guest1626>i've built those before, yes, and by built i mean (hopefully) fetched substitutes only. the first time i ran it was without the -v flags and I saw nothing at all until it was finished - even though in the process tree i could see it doing native compiling of .el files.
<nckx>Work done. Afraid I really need to go to bed, I just tried to eat my bed-time soup with a fork. Good night, good luck, all that.
<Guest1626>ok np good night
<Guest1626>thanks anyway
*lfam testing build of latest Apache httpd
<lfam>Let me know if you have a workload you want to test in the next hour or so
<lfam>"An attacker could use a path traversal attack to map URLs to files outside the expected document root"
<lfam>"This issue is known to be exploited in the wild."
<lfam>That's gonna be a "yikes" from me, dawg
<lfam>Patch for Guix: <>
<lfam>I'll be pushing it pretty soon
<apteryx>mbakke: "the stable 1.20 series which is scheduled for release in a few weeks time" ( I guess time will fix my mistake soon :-)
<jackhill>sneek: later tell podiki[m] I tested flatpak-next by building the package from the file you posted and then running it directly from the store. It still stared the p11-kit from /run/current-system rather than p11-kit-next. I checked before hand that no p11-kit was running.
<sneek>Got it.
<kenran>I've had my eyes on Guix for a while (as a current NixOS und Ubuntu user), but the thing that kept me from switching is my nix setup with home-manager and flakes that I can use on all my machines, including non-NixOS ones. But I've read that 'guix home' has been merged now and it looks like it could be used for this, but I'm not sure: can I use guix home on non-Guix systems as well? Or are there
<kenran>plans for that if I can't?
<lilyp>You should eventually be able to use it everywhere but despite the merge it's yet in a buggy state afaik
<lilyp>But if you want to be an early adopter, go ahead.
<kenran>lilyp: I wouldn't mind that, yeah. I'm currently installing Guix in a VM for now
***robin_ is now known as robin
<ennoausberlin>Hi. I yesterday tried to change my system config from dhcp to static. I got a hint here to remove network-manager-service-type from %desktop-services.
<ennoausberlin>(modify-services %desktop-services (delete network-manager-service-type))
<ennoausberlin>But I get invalid field specifier if I run guix system reconfigure
<lilyp>You're probably not nesting something corectly
<ennoausberlin>lilyp: I finally found an full example config.scm. I try to modify it to my needs now
<ennoausberlin>lilyp: I got it.
<vivien>Hello guix! I like the idea of flatpak. However, to use any application, you need to install a super-shared-object called a runtime. There are only 3 big ones: Freedesktop SDK, GNOME and KDE. The problem is these are only available by trusting flathub, a repository where a lot of non-free software is hosted. However, it seems simple to build a runtime: Maybe we
<vivien>could build the simplest one (freedesktop runtime, with guix? Has anyone tried?
<robin>vivien, i haven't tried, but if we could build drop-in replacements for the popular runtimes that would definitely be a win
<robin>it'd be nice if flathub separated free and nonfree stuff, but we can't do much about that (other than maybe coming up with a way to host a "freehub" subset)
<robin>(i also wish firefox had a "show me only free extensions" preference, which would eliminate a major reason for gnu having to maintain icecat...)
<lilyp>vivien even if we were to build that SDK, how would we use it as a drop-in replacement for the real thing?
<lilyp>perhaps we could write a `guix pack' exporter that generates flatpak sdks, however
<lilyp>According to Arch it only appears to be a bunch of symlinking and writing some metadata
<robin>we could, i don't think it would be all that difficult (maybe tedious)
<vivien>lilyp, when you want to publish a flatpak outside of flathub, your users will try to install it, and then they will get an error because they don’t have the runtime. So, the application publisher will have to write down something like "To install this flatpak, first authorize flathub to provide the runtime". I’m not OK with this, so I would also host the runtime. I imagine that if the names match, flatpak won’t complain.
<robin>flatpak might want hashes to match too? it's been a while since i worked with it... but we could just patch flatpak in that case
<vivien>I think you don’t need to provide a hash of your expected runtime when you build a flatpak application
<robin>sounds like a fairly straightforward project then
<vivien>The major drawback is partial upgrades, if you build a runtime out of the void, you will need to push all of it for each upgrade of a component.
<vivien>I think I could work with that though.
<vivien>Apparently you can switch runtimes with flatpak run --runtime=...
<robin>ah yes, flathub does have license metadata, so it'd be easy to separate the wheat from the chaff, i think (probably not quite to GNU standards, with things like firefox, but better than flathub)
<vivien>Yeah, I wouldn’t fully trust it
***iyzsong- is now known as iyzsong
<robin>tbh i just use firefox with no drm and no nonfree extensions, which would be halfway to icecat if i also disabled js
<robin>(imo as someone who worked on web standards for years, librejs is a good concept but the design is not fit for purpose on the modern web, not that i expect other GNUistas to agree with me)
<vivien>I hope most things will switch to RDF so we can replace web applications with our own (disclaimer: that’s what I’m working on :)
<ennoausberlin>Hi. How can I configure guix without gnome, but with graphical login e.g. sddm, slim? Is there a minimal example config.scm? I at the moment get xorg-server provided more than once
<mothacehe>hey guix!
<ennoausberlin>mothacehe: Hi. I got X up on my Pinebook Pro (compiled on the machine itself), xterm is started, but then it freezes. Neither keyboard nor mouse input.
<robin>vivien, RDF. now that's a name i haven't heard in a long, long time (i loved the RDF concept back in the 00s; i hope i still like it as much now that i've studied graduate-level mathematical logic)
<mothacehe>apteryx: the tests are almost fixed on the core-updates-frozen branch, what do you think of merging 50358 :) ?
<mothacehe>ennoausberlin: what procedure did you follow exactly? did you use the image at
<robin>vivien, what stage is your project at? (roughly speaking, e.g. is there code published somewhere yet, or still being designed, etc.)
<robin>ennoausberlin, iirc you should only have to replace "(service gnome-desktop-service-type)" in your config.scm with another DE or WM service, e.g. xfce, and replace the default gdm service with another display manager
<vivien>robin, for the runtime stuff, I’ve just started writing some gexps. For my web project, I’m trying to implement Solid ( in Guile. I already have an experimental server and an embryo of browser (the library can do most client things, but making UIs is a hard task).
<vivien>I wanted to know if I could build the browser as a flatpak.
<vivien>I’d like to have a generic browser that can be augmented with plug-ins to exercise specific ontologies, in the long term.
<ennoausberlin>mothacehe: Maybe not the latest, but not older than 2 weeks. Probably my config.scm is missing something. I just want to mention, that you don't need to cross compile, but it can be done on the machine itself. It took around 4 hours overnight initially with cpu governour set to powersave (battery is drained too fast on performance setting)
<robin>vivien, very cool. i'll have to read up on solid, i've seen the name but that's about it
<mothacehe>ennoausberlin: ok, could you share your config.scm :)?
*robin checks the bug list
<robin>i installed guix on a new computer this weekend and the graphical installer was broken (crash during the final stages of installation); hopefully i don't have to reproduce it for reporting :)
<ennoausberlin>mothacehe: I am at work right now. I will send you a mail later this day
<mothacehe>robin: did you use the 1.3.0 image or the latest one?
<mothacehe>many installer bugs are fixed on the latest image available here:
<robin>mothacehe, oh, 1.3.0. thanks for the pointer, i'll probably install guix on another machine or two soon
<robin>a friend who's a linguist is interested in how guix avoids -type messes, does anyone recall a paper on practical use of guix for scientific research? i think comparing it to docker and similar tools? (i can find it myself but it'll take a while)
<wigust>hi guix
<robin>maybe it was , though i remember the paper being a bit less focused on a specific application of guix
<jpoiret>any idea where default, sanitize and such are documented in the guile api for record specification? srfi-9 doc doesn't mention them
<jpoiret>disregard that, this is in guix/records.scm
<excalamus>good morning, guix!
<excalamus>I just had a problem with guix package -u. It complained about "profile contains conflicting entries". I followed the hints which suggested upgrading various packages by name. In the end, it was a =guix package -u qtbase tigervnc-server xfce4-panel= which allowed the operation to complete. It's not clear to me what happened to create conflicting entries. Also, it's not clear why listing the packages as I did worked, but trying them one
<excalamus>at a time didn't.
<excalamus>yesterday, or the day before, I recall there was a problem with the substitute server which may have been the cause
<excalamus>I would have expected a plain =guix package - would have the same effect as the call naming each package
<excalamus>er, =guix package -u=
<lilyp>excalamus: it's propagation
<excalamus>I only see one entry in the manual for that. I've seen it in the context of builds, like propagated-inputs.
<excalamus>C-s propagation
<roptat>hi guix!
<excalamus>is it something like there were propagated-inputs needed for one version and, on package -u, a different version was needed and that caused the conflict
<civodul>mothacehe: hey! did you observe changes on the "guix publish" front?
<lilyp>excalamus: exactly, when using propagated inputs you basically fall back to the logic of traditional package management
<mothacehe>civodul: hey! yes, I updated this ticket: In short, the patch removing the "system" field from narinfo doesn't improve the situation. I'll soon deploy the patch computing narinfo in a separate thread.
<vivien>Hello guix, I rebooted into guix home.
<mothacehe>is there any haskell hacker around? The ganeti build is broken on core-updates-frozen and i would appreciate some help :)
<excalamus>lilyp, okay, gotcha. Thank you
<civodul>mothacehe: ah, ok; thanks!
<ennoausberlin>mothacehe: Do you know if rust is working again on aarch64? It fails on check phase for weeks now. ripgrep and fd-find unfortunately depend on that
<civodul>on core-updates-frozen and "make assert-binaries-available" still shows a number of missing things
<ruffni>vivien: yay! how does it feel?
<vivien>ruffni, nautilus is very slow to open
<vivien>However, I’m able to install the glade catalog for libhandy
<vivien>That’s good.
<vivien>I’m trying to get deja-dup to work, but it’s not easy
<vivien>I get: "BackendException: Could not initialize backend: No module named 'gi'"
<vivien>I tried installing python and python-pygobject
<vivien>It’s not specific to guix home though.
<drakonis>when is core-updates-frozen getting merged?
<drakonis>its been frozen for a few months now?
<lilyp>We're trying to create ice-9, might still take us some 9 weeks or so :)
<makx>does guix containers somehow support creating network namespaces? do I have to hack that up myself?
<civodul>drakonis: we're still working on it, help's needed! :-)
<lilyp>jokes aside, the ML is currently discussing the last (wink wink nudge nudge) world rebuild
<drakonis>heh, when isn't it ever?
<civodul>you can try upgrading your profile or system to it, or test things in a VM
<civodul> shows the status of system tests
<civodul>and then you can also run "guix weather" to see packaging status
<awb99> can someone tell me which package/service I need, so that the os would mount newly attached USB disks ?
<awb99>auto mount.
<lilyp>udisks probably
<civodul>awb99: i think it's supposed to "just work" if you use GNOME or Xfce for instance
<awb99>thanks lilyp civodul !
<civodul>but i've seen cases where it wouldn't
<civodul>so i'm not sure
<civodul>udisks is involved, but installing it is not enough
<lilyp>oh right, if it's an ntfs volume, you need ntfs in your OS packages
<civodul>oh, could be that
<lilyp>I always forget people don't typically use ext4 formatted usb sticks
<vivien>Is anyone using deja-dup on guix?
<jpoiret>drakonis if you want some feedback i'm currently running core-updates-frozen for my system and it works well
<lilyp>version 40.6 looks suspicious
<drakonis>ah, good.
<jpoiret>sway 1.6 in it fixes the flickering popups, which is the reason i upgraded (apart from Wayland support but i had been running on my pending patch for a while)
<mfg>jpoiret: what kind of flickering popups in sway do you mean? i have some in firefox and am on sway 1.5.1 so is this solved with 1.6?
<lilyp>hmm, 40.6 might be okay unless it's been broken since May 2020
<vivien>I tried to use it in guix home and in its own environment, both fail
<lilyp>since when?
<vivien>Today ^^
<vivien>I tried it first today, and it failed first today
<vivien>(I’m using a bit of free time to set up both guix home and deja-dup)
<vivien>On core-updates-frozen, irrlicht doesn’t build (for minetest)
<awb99>jpoir: do you have a sway config? Is wayland running nicely with sway now?
<mbakke>how do I make a program look for PAM modules outside of /gnu/store/...-linux-pam-1.51/lib/security (i.e. a third party module)?
<jpoiret>awb99 my sway config is mostly the default one, and it is (and has always been running nicely)
<jpoiret>the difference is that now GDM supports wayland sessions
<jpoiret>(in Guix)
<awb99>jpoir - thanks. does sway wayland need any special config? will sway by default be wayland?
<jpoiret>mfg: yes, the ones with firefox for example, and they are indeed solved
<jpoiret>awb99: sway is a Wayland compositor, it only supports Wayland as a display protocol
<jpoiret>although you can run X apps in it using Xwayland
<mfg>jpoiret: amazing! i'm tempted to try core-updates-frozen out :D
<jpoiret>if you can afford to, you should, it's working smoothly for me (after a single patch because `light` wasn't compiling anymore), and most things are already substituted
<jpoiret>also that'll help finding blind spots and merging it faster
<vivien>Emacs users on guix, does tramp work on your box? If I run (tramp-dissect-file-name "/sudo::/") I get "Wrong type argument: stringp, nil".
<mfg>jpoiret: i see, i'm going to try it then :D
<lilyp>tramp does work for me with sudo
<jpoiret>vivien: currently on core-updates-frozen, but i do not get such an error
<awb99>thanks jpoir
<lilyp>the only weird thing is authentication, as I'm trying to set up things with libsecret in a way that is not completely bonkers, but haven't yet gotten to a good configuration
<jpoiret>i'm having trouble trying to implement a way to warn users that a default value for some configuration is going to change soon, in a way that is not completely chaotic
<jpoiret>currently i'm doing the same as the target->targets renaming, however since the service-type definition provides a default configuration (which is thus evaluated), it will always print out a warning message corresponding to that default configuration
<jpoiret>i'll provide a paste
<roptat>so yesterday I tried packaging something new, but had troubles finding the source. The package is under gpl2, but it seems the source can only be downloaded after giving your name email and completing a google captcha :/
<roptat>in the end, I could get a link like https://..../download?uid=abcdef123456
<vivien>lilyp, is tramp-file-name-structure set to nil?
<vivien>OK so my error is probably here ^^
<roptat>the link worked for some time, but I'm not sure it will continue working for too long, especially if many guix users keep using it ^^'
<jackhill>robin: I don't have a great thing point you to, but I'd look for some examles via I'd also note that outreach resources are one of the things we want to work on
<roptat>what should I do? would it be acceptable if I host the source somewhere else?
<roptat>uh nevermind, I just found out they have a github repository... that will be a lot easier
<roptat>oh no, it only contains the code of their website ^^'
<vivien>OK, so my error was somewhere within .emacs.d, I purged it and tramp works now :)
<jpoiret>when guile complains of a records ABI mismatch, which file should i delete and recompile?
<jpoiret>i keep deleting the .go corresponding to the one throwing the error (as documented in (guix records)) but it keeps complaining
<civodul>jpoiret: when in doubt, you can always run "make clean-go && make"
<jpoiret>i hadn't heard of that `clean-go` target
<jpoiret>it'll do for now, but i really want to know how to actually fix the problem in the first place
<civodul>with experience, one can often delete & rebuild only the relevant files
<jpoiret>but i should have known since i just modified `service-type` to have a delayed field
<civodul>ah yes, so in that case you'd need to rebuild every file that uses (gnu services)
<jpoiret>i'm currently only testing this out, but do you have any idea if delaying `default` would be detrimental?
<jpoiret>civodul: true, but it looked like only the one i was modifying was throwing out the error
<roptat>jpoiret, that's because it was the only one being recompiled
<roptat>the rest would have kept using the old macro
<jpoiret>i'd love to know what problem the ABI code in (guix records) is supposed to avoid as well, since I don't think it documents what *actually* would go wrong
<roptat>at least I think that's how it works
<roptat>it wouldn't work as expected, some services would have a delayed default, and others wouldn't
<podiki[m]>jackhill: hi, yes, I saw the same thing. I think flatpak uses its session helper (I see a .flatpak-session process), and it may just launch based on PATH?
<sneek>podiki[m], you have 1 message!
<sneek>podiki[m], jackhill says: I tested flatpak-next by building the package from the file you posted and then running it directly from the store. It still stared the p11-kit from /run/current-system rather than p11-kit-next. I checked before hand that no p11-kit was running.
<podiki[m]>jackhill: after I got rid of other flatpaks and cleaned up any processes it worked. so probably need to find where it calls session helper to make sure it launches its own version? but should work if just one flatpak bin
<podiki[m]>jackhill: hmm, it might be sending these commands via dbus, not sure how to handle if there is another flatpak install. should work with just one flatpak-next installed
<dissoc>i've been getting the error "guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet." . i also get it when pulling. i havent noticed any networking issues other than this. any ideas?
<dissoc>a download or pull will stall and fail. sometimes it succeeds. not sure how to debug
<minikN>When I run `guix install ...` I get the error `unsupported manifest format`.. I just ran `guix pull` before. What did I do?
<roptat>minikN, what's the full command?
<minikN>any package you want, happens with all of them
<minikN>I wanted to provide a newer version of the flatpak package on my own channel. After I pulled it failed while building the package cache. I noticed an error in my package definition and fixed it. Then I could pull just fine. But now I'm getting this error when running guix install with every package.
<roptat>sorry, I don't know what happens
<Inline>what does spurious SIGPOLL mean ?
<roptat>minikN, maybe remove your channel and see if it helps?
<minikN>roptat: nope
<roptat>can you roll-back your profile and try again?
<minikN>Roll back to what? I didn't reconfigure my system nor did I install any package in any profile
<roptat>so you don't have any profile?
<nckx>Morning Guix.
<minikN>I think I don't get what you mean. I do have profiles, but I didn't install anything in them that could have caused this
<minikN>Hi nckx
<nckx>Inline: For users, something irrelevant that they can ignore. For the code, see <>. Basically a signal is arriving unexpectedly late, a ghostly echo from the past.
<nckx>Hi hi ☺
<Inline>ok thank you nckx
<nckx>This looks like Old Nix Code.
<Inline>hmm, i started guix-daemon manually and i see that message from time to time
<jackhill>podiki[m]: indeed, I still had the master flatpak version installed in my default profile. I'll try removing that and trying again.
<nckx>Yeah, I recognsied it ☺ It's a ‘this shouldn't happened but Eelco noticed that it did but it's harmless but still print an error to remind him to debug it later which he apparantly never did.’
<nckx>Like most Old Nix Code, Guix is still carrying it many years after Nix deleted it (in 2014!).
<nckx>They just switched to a totally different mechanism so the oddity was never investigated:
<minikN>nckx: I got that `Derive` error again. This time on a new SSD:
<jab>so apparently jabber.el lets you transfer jabber accounts pretty easily. that's kind of awesome.
<podiki[m]>jackhill: my brief investigation didn't turn up much, I think it must call it's session-helper via dbus, so I'm not sure there's a way around it
<podiki[m]>jackhill: but I think will be an okay workaround for p11-kit until the next core-updates cycle. I've also updated and fixed some flatpak and portal issues, will submit patches soon
<podiki[m]>minikN: I have some newer flatpak stuff if you wanted to see. and just doing a --with-source transformation builds 1.11.3 just fine
<minikN>podiki[m] This isn't about flatpak anymore. My store is corrupted.
<podiki[m]>gotcha, just meant if you were interested in newer flatpak stuff
<nckx>I have no idea what could be happening, sorry…
<minikN>podiki[m] I'll either get it fixed rn or I'll go back to another distro. This isn't the first time this is happening (nckx knows abou it) and I
<minikN>I'm fed up with it
<podiki[m]>sorry to hear that. I had a hosed store from doing a (probably misguided) "backup" and restore with filesystem change, but that was my fault
<nckx>This is bizarre.
<minikN>podiki[m] Oh I would love for this to be my fault, then at least I could reproduce what I'm doing wrong, but every time this happens (4h time now) I do something completely different. This time I didn't even reconfigure my system, I simply pulled with a bad package definition in my channel, how this can corrupt my system is beyond me
<podiki[m]>I echo nckx, sounds bizarre
<podiki[m]>and I'm guessing you've checked hardware stuff like ram, storage.....your cosmic ray shielding?
<nckx>I'm afraid they might even have bought a new SSD…
<minikN>Last time nckx suggested bad SSD, so I got a new one..
<minikN>Yeah exactly
<podiki[m]>confirmed nckx is in big SSD's pockets??? :-P
<podiki[m]>hrm. the weirdest errors I've had from hardware have been power supply going, and ram, since both will do very random things
<nckx>As someone who struggled to buy their first SSD I feel kind of bad. OTOH, this is genuinely baffling. It's not ‘your’ fault but there seems to be something cursed about… well, something about you(r system). Were all 4 times on the same machine?
<podiki[m]>power supply is hard to diagnose though. i've had bad thermals probably more quickly killing things than they should too
<minikN>nckx Yes.
<Inline>duh, i installed some packages and also some others in an environment, and the build seems to take ages
<Inline>is running guix processes in parallel safe ?
<Inline>i have two terminals one with normal install the other with environment install
<Inline>guix processes shows them all, but not sure why it takes that long
<nckx>I understand it can feel cheap or lazy of us to blame your hardware but that's really what it sounds like. Yes, Guix has plenty of bugs, but not *this* AFAIK. And Guix might stress your system in ways other distributions don't. I'm out of ideas (was last time, in fact).
<Inline>it's running since early morning today
<nckx>Inline: It's safe.
<Inline>ok thank you nckx
<Inline>btw do you know if i can get a more complete description of what's going on when installing packages ?
<nckx>Inline: What's building?
*nckx 'phone.
<Inline>gnu packages and the other is guix environment --pure guix --ad-hoc --container $(guix search lisp|grep ^name |awk '{print $2}'|sed -e 's/^ecl.*//g' -e 's/^emacs.*//g' -e 's/^python.*//g'| xargs -n1)
<podiki[m]>hardware does sound possible, changing storage did sound like a good idea (I find Guix more storage intenstive). but unfortunately there's lots of other pieces on the way to data being written :(
<Inline>i'm on x86_64
<minikN>nckx: I don't blame you. Maybe it is the HW, maybe. But I can't justify replacing other parts of my system for financial reason. And this literally breaks my heart, because I want to stay on Guix, I love the idea behind it, first distro I've ever used where I felt like "this is it, I don't need anything else". But I also can't justify reinstalling my os once a month, so back to void it is I guess.
<podiki[m]>I hear ya minikN, that is frustrating. guix does make it easy to regenerat the system, but definitely not something you should have to do all the time
<nckx>minikN: I fully understand, and I've been in the same position (you will *never* hear me say something stupid like ‘spinning rust’ or ‘storage is cheap’ for that reason). It's frustrating not being able to help, or point to a known bug.
<nckx>I'm also still frequently frustrated by Guix's promise in the abstract and the warts in its earthly implementation ☺
<nckx>minikN: Which root file system(s) did you use for your attemps?
<minikN>3x ext4, 1x btrfs
<nckx>And, to ask the obvious, btrfs never reported any checksum or scrub errors?
<minikN>I was on btrfs when it happened the last time (and I talked to you for the first time) I ran that ssd test you suggested as well as the btrfs scrub check. Both returned without errors, but again I changed ssds anyway
<nckx>Inline: ‘guix environment’, ‘install’ etc. should all accept a --verbosity=3 (or whatever, chosen at random because it shows build output here) argument. Unfortunately you'd have to cancel running builds to test.
<Inline>right, and also i'm using a subshell
<Inline>that's unfortunate too
<nckx>Inline: By the way, while it *is* safe to launch multiple guix package builds, that doesn't mean your machine might start to struggle, particularly if it starts swapping, which will make doing the same work orders of magnitude slower.
<nckx>Sorry if I'm pointing out the obvious. ☺ It's hard to know what's obvious.
<Inline>ok there's no need since i use xargs i can just pass that to guix install
<nckx>s/might/might not/
*nckx 's Debian Gitlab account that I created yesterday just got ‘approved’. I can't even remember which bug I was going to file. So… that's 1 point to Guix, at least.
<jackhill>… I thought DEBian used DEBbugs as well
<dstolfa>jackhill: they've moved to gitlab a while back
<jackhill>huh, interesting
<podiki[m]>jackhill: since you've been flatpak-ing, anything else we need to fix? I will have a patch (from nix) to remove the store path from desktop files flatpak makes
<podiki[m]>as well as updating the portals to latest versions
<jackhill>podiki[m]: I can't think of anything, but I'm not a heavy flatpak user. I use three paks which I launch from the command line. Certs was my only complaint.
<jackhill>I don't think destkop portals are working for me with sway, but I haven't really investigated that to know where the problem lies
<podiki[m]>all I know is there is a portal for wayland, but no experience with that. I'll check if it needs an update too
<civodul>GNUtoo: hi! did you write about how you use Guix for Replicant?
<civodul>that could be interesting reading :-)
<civodul>roptat: seems to be down
<roptat>civodul, yes, and I won't be able to fix it until this week-end, sorry
<civodul>i was considering playing with guile-netlink
<roptat>that server is not the most reliable :/
<roptat>so, same question as this morning, I was trying to package gplates, which is under gpl2, but its source is kept behind a captcha (and it seems to generate a random number, so even if I was able to get the sources, I'm not sure the link will always work)
<roptat>what should I do?
<GNUtoo>civodul: you mean on the GNU/Linux libre mailing list?
<GNUtoo>We used it for several things:
<GNUtoo>(1) To download Android source code, you need a tool called repo,
<GNUtoo> unfrotunately when you use it it auto-update itself,
<roptat>GNUtoo, I have some guile code that completely replaces repo
<GNUtoo> And newer repos need newer python than the ones in Trisquel, so I released a repo binary to fix that:
<civodul>GNUtoo: i saw you mention it on gnu-linux-libre, and i thought it'd be worth expanding a bit in a blog post or something
<GNUtoo> The details are in the README
<civodul>looks like an interesting use case
<civodul>(and a useful one!)
<civodul>roptat: is the code mirrored somewhere?
<GNUtoo>(2) we use a guix.scm to build libsamsung-ipc and libsamsung-ril for Android and GNU/Linux with various compilers and so on
<nckx>roptat: Do you mean ? I didn't have to solve a puzzle and it says ‘Note that these links do not expire.’
<roptat>ok, then it's not a problem
<nckx>Links are of format /download/8421/?uid=551c9ced95
<roptat>yeah, I got a different uid
<roptat>the tar.bz2
<nckx>I just ticked other, no other fields.
<nckx>Maybe it's a hash… prolly not though.
<nckx>I mean, of the inputs, the kind we like.
<nckx>Choir: ‘it was not’. Oh OK.
<Inline>i think they both lock and one is waiting for the other
<Inline>oh man
<nckx>Still works without the hash though, so I don't think it's worse than any other exotic forgey thing.
<roptat>anyway, if the link doesn't expire, I think it's good enough
<Inline>ghc-guile-emacs takes ages
<GNUtoo>civodul: we also use it on the server for matterbridge but I messed up
<GNUtoo>I sent a patch for it and I only notified at the last time that I didn't know how dependencies worked in go and so on
<GNUtoo>*at the last moment
<nckx>Inline: Yes, it does that. It's like one big make job.
<GNUtoo>And after learning more about go I found that it had tons of dependencies...
<Inline>what does no-auto-compile mean ?
<Inline>why shall it not compile if it is building on my arch ?
<civodul>GNUtoo: interesting
<GNUtoo>Like about 560 dependencies, I've reviewed the licenses of many unknown, and everything is fine, but guix import didn't add all the dependencies though
<nckx>Because you don't always want a cached .go created of, e.g., a simple script? Hard to answer that question generally.
<nckx>Inline: ☝
*nckx ded, → 😴💤
<nckx>Night Guix.
<GNUtoo>Though now it fails, and I'm not sure anymore of the syntax
<GNUtoo>it's 'guix import go' ?
<GNUtoo>(4) Ideally I'd also like to add the ability to install Guix to Replicant 11. I still need to package at least xz and gpg in Replicant though
<GNUtoo> The idea is to add what the guix-installer script requires and probably modify it a bit to be able to install it on Android (as you pointed out in your blog post, Android doesn't have /etc/groups for instance and I don't think that adding groupadd would be the solution here as many users and groups are hardcoded in Android)
<GNUtoo> Though it probably have some way to add groups and users since applications have dynamic groups and users ids, but I've no idea if that's usable for things like Guix
<GNUtoo>We also need to make sure that in general Guix stays FSDG compliant as it would be quite problematic here if for some reasons it stops being the case
<civodul>that won't be the case
<civodul>i wonder whether building a Replicant system using the Guix System tooling would be feasible
<GNUtoo>What could be done would be to add an Android target though
<GNUtoo>like we have x86_64-w64-mingw32 for instance
<GNUtoo>So if we add some arm-*android-* target we could probably build binaries for Bionic
<civodul>ah right
<GNUtoo>The big question here would to know how much bionic is linked to the kernel headers, but the SDK probably targets a wide range of kernel versions anyway
<GNUtoo>So it's probably not a big issue, just something to keep in mind
<awb99>I have horrible problems with virtualizations. Whenever I run a simple xwindows qemu image, or a docker image with xwindows, my machine virtually freezes.
<awb99>I run it from guix system
<awb99>Either virtualization is not supported well, or perhaps I run into memory issues.
<awb99>I noticed that guix by default does not create a swap file.
<awb99>I have 32 gig ram.
<awb99>so not sure if this is the issue.
<civodul>awb99: for X11, you need to make sure the VM itself has ~2G of RAM or more
<civodul>that's "-m 2048" if you use QEMU
<civodul>GNOME might need a bit more, even
<awb99>thanks civodul
<jgart_>Hi Guix
<jgart_>does anyone happen to know why this is so:
<jgart_>I can only use emacs-commander as a library to write an eshell script from a guix environment if I make it available like this:
<jgart_>guix environment emacs-commander --ad-hoc emacs-commander
<civodul>jgart_: hi! when you run "guix environment emacs-commander", you are *not* providing emacs-commander in the environment
<jgart_>It seems a bit verbose to use an elisp library
<civodul>instead, you're providing its dependencies
<jgart_>civodul: so, I have to specify it twice?
<civodul>no, once is enough
<jgart_>with --ad-hoc you mean?
<civodul>however, if you just write "guix environment --ad-hoc emacs-commander", EMACSLOADPATH won't be defined
<GNUtoo>civodul: as for FSDG my idea is to somehow get the distributions involved in the decisions as this has various advantages (like making sure people take decisions that take into account the reality of distributions, enabling more people to learn about the FSDG, alleviating FSF's work, etc)
<jgart_>that doesn't work
<jgart_>--ad-hoc by itself doesn't work
<jgart_>as I described on the mailing list
<GNUtoo>It also looks important for distributions like Replicant that does almost everything differently
<jgart_>atleast it doesn't work on a foreign distro (I'm using guix on void linux)
<civodul>jgart_: yes, see above :-) so you need, say, "guix environment --ad-hoc emacs emacs-commander", and only then can Guix know that it has to define EMACSLOADPATH
<jgart_>I haven't tested with Guix System yet
<jgart_>I already had emacs in my default profile
<civodul>GNUtoo: sure, makes sense!
<jgart_>do I have to add it a second time in the environment?
<civodul>jgart_: yes, because "guix environment" doesn't know about your default profile
<jgart_>oh ok
<podiki[m]>jgart_: there was a response too (saying largely the same thing)
<jgart_>wouldn't it be nicer to have those two things know about each other?
<jgart_>or would the implemention be to hairy?
<jgart_>podiki[m]: I read that but it doesn't mention adding emacs also to the environment via --ad-hoc
<civodul>"guix environment" is purposefully self-contained: its behavior does not depend on things that happen to be in ~/.guix-profile, etc.
<civodul>that makes it predictable, reproducible, tec.
<Inline>welp, i'm on top of voidlinux, i can see how my system looks like via guix home import
<jgart_>civodul: thanks for the explanation
<Inline>but i think i don't have an explicit conf.scm anywhere for it
<jgart_>I think I'll just make a wrapper script so I don't have to explicitly reference emacs everytime I want to use an elisp library
<Inline>at least not that i see in /var/guix
<Inline>is it still possible to me to have a /etc/conf.scm like config somewhere ?
<podiki[m]>Inline: on a foreign distro you won't have a system configuration (though you can still make one to make images out of, for example)
<Inline>i only see a /etc/guix/acl nothing else in there
<podiki[m]>and that is separate from guix home
<Inline>i mean other than the acl file
<podiki[m]>question on patches: I have various updates for flatpak and its portals, should I base that off master or core-updates-frozen? I think they are the same here, but recent build failures on core-updates-frozen this would also fix
<podiki[m]>Inline: system configuration only makes sense on guix system, as it sets up things like filesystems, boot, users, etc. (and system-wide packages)
<Inline>so i don't need it, ok then
<Inline>thank you
<podiki[m]>Inline: but there are samples in the guix code you can play with in a VM or off a USB to boot from (that you can build with just guix on foreign distro)
<jgart_>has the mkdir permission error been fixed with guix home on a foreign distro yet?
<jgart_>or is anyone working on it?
<civodul>jgart_: idk, but to be sure, you can report a bug, possibly Cc'ing Oleg or yoctocell
<jgart_>Oh, Maxime's suggestion from 39 hours ago fixed it for me
<jgart_>export XDG_RUNTIME_DIR=$HOME/tmp
<jgart_>I'll reply now to let them know
<Inline>i just change profile to XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR:.......
<Inline>so hostOS path is prepended not appended
<Inline>and i did that with all the rest of variables in profile too
<maximed>civodul: is now a good time for the ‘ttyl’?
<maximed>It would be about making the ‘source manifest’ a GC root I think
<GNUtoo>About XDG_RUNTIME_DIR, what should it be set to?
*GNUtoo managed to run weston with XDG_RUNTIME_DIR=/var weston
<GNUtoo>but so far I didn't manage to run other graphics windows manager yet on my laptop (i686)
<GNUtoo>(it's on GuixSD)
<GNUtoo>civodul: when I think about it, with Android, once everything is in place, and importer should be doable
<GNUtoo>Most repositories uses or Android.bp, these can be parsed
<GNUtoo>And as you have scheme code for repo, you could also parse manifests
<civodul>i guess roptat has ideas on how to get there :-)
<GNUtoo>Though it would still require some interactions to find the or Android.bp as git find on remote repositories probably doesn't work
<GNUtoo>*doesn't exist
*civodul nods
<jpoiret>is there anyone with knowledge of (guix records) internals, especially the ABI conundrum?
<maximed>It's like how changing the definition of a 'struct' in C requires rebuilding things
<jpoiret>yes but why doesn't guile automatically rebuild the offending .go file?
<maximed>jpoiret: Because guile doesn't have that functionality
<maximed>would be nice to have though
<maximed>I've written a patch doing something like that (but not precisely),
<maximed>Search for 'notice-dependency' at
<jpoiret>oh alright, that's just because guile doesn't really have a "use-module tree" according to which it knows which dependencies should be recompiled
<maximed>I suppose the definition of the '(package ...)' macro could be modified to call 'notice-dependency'
<maximed>Such that if guix/packages.scm is modified, all modules using the 'package' macro are considered in need of recompilation
<jpoiret>heh, i'm more in favor of something more interactive
<jpoiret>ie here i'm working on service-type
<maximed>jpoiret: what do you mean, more interactive?
<jpoiret>i mean, tell guile "here, i modified this file, what do i need to recompile?"
<singpolyma>But if it can tell you why wouldn't it just do it instead of making you do work?
<jpoiret>mhm yes alright, i understand it a bit more with your patch too, there just isn't a way to build that dependency tree unless you manually insert some notify-dependency somewhere yourself
<jpoiret>maybe in define-record-type* though, this would get some mileage
<GNUtoo>btw, I had a typo before with guix import, and I needed to remove the https://
<maximed>jpoiret: What the patch does is automatically recompiling the necessary dependencies when running "make"
<maximed>(at least in the guix source tree)
<maximed>so you wouldn't need to ask what files to delete & compile
<maximed>Instead, you'd just run "make" as usual
<maximed>jpoiret: Would you be interested in writing a patch to do that?
<maximed>(Note: notice-dependency is not in guix currently)
<jpoiret>yes, but you do need to use notify-dependency in the dependent file to record the one it depends on, right?
<maximed>jpoiret: not necessarily, adding it to the 'package' and other such macros should be sufficient
<jpoiret>doesn't package leverage define-record-type* ?
<jpoiret>if so then that would be even simpler, although i'm worried about the cost
<maximed>yes, so modifying 'make-syntactic-constructor' should be sufficient
<maximed>jpoiret: There's only a tiny cost at expansion time
<jpoiret>i'm not proficient enough yet to fully understand how guile compiles files, and what would be the breaking ABI change
<maximed>An entry is added to a hash table somewhere (no disk I/O)
<jpoiret>.go are expanded and compiled files, right?
<maximed>Expanded, compiled, optimised & serialised. (possibly with some inlining, depending on optimisation settings)
<maximed>At worst, something won't be recompiled when it needs to be, though then that ‘guix: ... ABI error’ will still result
<jpoiret>but then, what is the breaking change for ie records? if the accessors are defined and compiled in "dependency.go", if they are recompiled with changes, won't files that depend on it use the newly compiled procedures?
<maximed>So it oxouldn't be orse than before
<jpoiret>maximed: true
<maximed>jpoiret: Accessors can be inlined
<maximed>Possibly the call to the record constructor (the procedure make-package, not the macro make-package) as well
<jpoiret>oh okay! i assume they're inlined by default too
<jpoiret>right, then i think adding the notification to make-syntactic-constructor would be the way to go
<jpoiret>although i still can't really read the code in that module properly (haven't worked on syntax at all)
<jpoiret>we'd need to single out common inlining points and add notify-dependency
<maximed>notice-dependency needs to know the file name of the dependency
<maximed>So you might need syntax-source
<maximed>Guix defines a few procedures for determining source information by itself
<jpoiret>although wouldn't you agree that guile directly recording dependencies when it inlines would be far more practical? maybe an upstream patch could achieve a similar result albeit more generally
<maximed>So maybe something different from syntax-source.
<jpoiret>yes, i've seen some current-source-location use