<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 inria.fr git?
<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?
<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.
<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>People use all kinds of clients that have all kinds of different features (we didn't know yours until that kiwiirc.com 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.
<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.
<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
<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: https://wiki.archlinux.org/title/Flatpak#Creating_a_custom_base_runtime Maybe we
<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>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)
<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 :) ?
<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>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>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 https://xkcd.com/1987/ -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)
<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>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: https://issues.guix.gnu.org/50040. 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.
<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
<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 :/
<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?
<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.
<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]>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
<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).
<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 :(
<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?
<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.
<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.
<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)
<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>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)
<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)
<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>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