IRC channel logs

<Guest63>It is Guix System installed without any DE.

<Guest63>Well, I think it does not make much sense I am doing anyways, since I just want to scale the display from the console

<Guest63> https://data.guix.gnu.org/statistics gives 504

<Slambert>Hello! I'm interested in getting into GNU Guix, and I've been wanting to use a system with no substitute packages.

<Slambert>I've been trying to configure this in config.scm for a while now using official and unofficial documentation, and I still

<Slambert>haven't gotten anywhere. Does anyone know how to properly disable substitutes in config.scm?

<stikonas>Slambert: not sure about config.scm but you should be able to get that easily with guix --no-substitutes

<stikonas>which you can probably even alias with bash alias guix='guix --no-substitutes'

<stikonas>guix daemon also seems to have that option

<Slambert>I was able to get it to work in config.scm (the reference guide is great!), but thank you for the support!

<stikonas>well, I only have foreign guix at the moment, so couldn't help more

<stikonas>used to have a full one but I think I was always manuallyh adding --no-substitutes

<Slambert>That could work, but I'm using GuixSD as a declarative system that I want to redeploy on multiple machines.

<Slambert>Having to put an alias in that machine's .bashrc file to get the result I want would make deploying my config to a new system more difficult.

<Slambert>I still think "guix --no-substitutes" works great, however!

<stikonas>well, your method is obviously better

<stikonas>though if you deploy on multiple machines, maybe you need to think about your own substitutes

<stikonas>otherwise all machines will be building the same stuff

<Slambert>That's what I'm going for.

<Slambert>I'm trying to see if I'm patient enough to not use substitutions.

<Slambert>Also, having a config that could deploy, say, a media server would could be really useful.

<stikonas>it will take quite a bit more time to build due to guix being declarative, more than random source based distro

<Slambert>Makes sense. I've experienced Gentoo before and I'm using strong hardware, so I think I'll be fine.

<daviid>dear guixes, i have two quiz related to the packaging of g-golf in guix: (1) i'd like to thank the guix team, when i search for g-golf - https://packages.guix.gnu.org/search/?query=g-golf - i now see that the first entry is (now) 'g-golf 0.8.0-a.1' [no renaming, as i was asking, thanks!]; (2) could i suggest that the other entries use a postfix pattern, like 'g-golf 0.8.0-a.1-guile-2.2''g-golf 0.8.0-a.1-guile[-3.0]', as this would also

<daviid>keep the package name as the first (and invariable) word? many thanks

<footlong>"Search — Packages — GNU Guix" https://packages.guix.gnu.org/search/?query=g-golf

<piapiac>Does anyone know what could be causing this error? guix deploy: error: failed to deploy <host>: SSH authentication failed for '<ip>': Failed to read private key: /home/kitty/.ssh/id_ed25519

<piapiac>The key file exists, has permissions 600, and I can ssh into the machine normally with it without issues x_x

<apteryx>I just sent a patch series to #32026, in case anyone has a needed for a localized IceCat/Icedove

<footlong>"IceCat locales are missing?" https://issues.guix.gnu.org/32026

<unmatched-paren>hello guix :)

<unmatched-paren>ACTION sent v4/v5 of dissecting guix 2 :)

<iyzsong>unmatched-paren: great, and thank you!

<sneek>iyzsong, you have 1 message!

<sneek>iyzsong, lechner says: / thank you for that pointer!

<n1tram1>join #hurd

<attila_lendvai_>is shepherd running on multiple threads, or only one kernel thread driving multiple fibers?

<mfg[m]>unmatched-paren: Many thanks for investing your time to write the dissecting guix blog posts :)

<attila_lendvai>to answer myself: shepherd's fibers setup is a pure cooperative one, i.e. a single kernel thread and no preemtion

<futurile>morning Guixers!

<mfg[m]>heya o/

<efraim>I might have to add a vim team and add myself to it

<jgart[m]>What would be the best practice for making the sfeed theme configurable?

<jgart[m]> https://git.codemadness.org/sfeed/files.html

<footlong>"Files - sfeed - RSS and Atom parser" https://git.codemadness.org/sfeed/files.html

<jgart[m]>Should I turn the sfeed package into a function that accepts the theme as an argument?

<jgart[m]>And then make an sfeed, sfeed-mono-highlight, sfeed-templeos, and sfeed-newsboat package?

<jgart[m]>My current thinking is that the theme argument would be passed to make-flags list https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/suckless.scm?id=67d2f688fb89553df53e73a4c584b1b9eb7d5c24#n1132

<footlong>"suckless.scm\packages\gnu - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/suckless.scm?id=67d2f688fb89553df53e73a4c584b1b9eb7d5c24#n1132

<jgart[m]>More context regarding setting the sfeed theme: https://git.codemadness.org/sfeed/file/README.html#l27

<footlong>"README - sfeed - RSS and Atom parser" https://git.codemadness.org/sfeed/file/README.html#l27

<jgart[m]>WDYT

<futurile>efraim: is your Fosdem talk video being made available?

<rekado>jgart[m]: all these package variants would be built by the build farm. I’m not sure pre-defined customization like that is the right approach for suckless stuff.

<jgart[m]>What do you suggest instead?

<rekado>jgart[m]: I don’t :)

<jgart[m]>What would you do as a guix user who wants to use sfeed with a different theme?

<jgart[m]>Also, why is it a problem that the package variants would be built by the build farm. Can you explain why that is a problem?

<rekado>the suckless stuff is very opinionated about configuration. You need to patch the applications yourself to configure them. So as a user of sfeed I’d write myself a package variant that includes the patch or I’d use package transformations on the command line.

<rekado>I didn’t say it’s a problem. I just think it’s not the right approach for suckless stuff.

<jgart[m]>Using a different theme with sfeed does not require any patches

<jgart[m]>It just requires setting an environment variable. The Makefile takes care of the rest

<jgart[m]>TLDR: I'm referring to this line in the Makefile https://codemadness.org/git/sfeed/file/Makefile.html#l7

<footlong>"Makefile - sfeed - RSS and Atom parser" https://codemadness.org/git/sfeed/file/Makefile.html#l7

<jgart[m]>It just requires the user to reassigning the environment variable SFEED_THEME to a different value

<jgart[m]>s/reassigning/reassign

<jgart[m]>Therefore why I'm thinking to make a function for the sfeed package that takes the value for SFEED_THEME as an argument.

<efraim>futurile: the one about guix on riscv or the one about custom minimal guix system images?

<futurile>efraim: minimal images

<efraim>actually the answer to both is I was hoping someone else would review them to make sure the timings were correct but I should've done it last week

<efraim>so yes, soonish™

<efraim>re package variants, we could mark them as not substitutable

<efraim>rekado: I saw you added metacity, and I saw from the inputs you hate the alphabet ;P

<efraim>... and go support for riscv64 is now live!

<jgart[m]>rekado: This is what I was referring to for sfeed. I implemented it here: https://git.sr.ht/~whereiseveryone/guixrus/commit/5c94120c937a6ddd56c787907908296aa0ebd6a7

<footlong>"~whereiseveryone/guixrus: packages: suckless: Add sfeed*. - sourcehut git" https://git.sr.ht/~whereiseveryone/guixrus/commit/5c94120c937a6ddd56c787907908296aa0ebd6a7

<rekado>efraim: sing along: L, Z, L, L, G, P, G…

<jgart[m]>Should I upstream that? It makes it convenient for using different themes with sfeed in a declarative way.

<rekado>efraim: sorry about that. I really did mean to sort them.

<efraim>still hunting down the tar failure on i686 on core-updates

<efraim>it might be the gzip-mesboot still in the environment. gzip gets used in the testsuite

<efraim>nope, wasn't gzip

<rekado>Sugar fails to launch because it uses GLib.spawn_command_line_sync; Python complains that only one argument is provided, but it wants two.

<rekado>when I provide 0 as the second argument it captures outputu.

<rekado>*output

<rekado>the glib examples I’ve seen don’t mention a second argument

<efraim>I think I found the issue with tar. It looks like between coreutils-9.0 (for 'stat') and tar, one of them is using 64-bit time on 32-bit platforms and the other isn't.

<wdkrnls>Dear Guix, I have been getting stuck trying to append manifests. This is possible, right?

<gabber>wdkrnls: what exactly have you tried?

<gabber>there is a `concatenate-manifests` function, but i don't think this option exists for command-line usage

<wdkrnls>I tried two approaches. First, I tried (append (packages->manifest ...) (specifications->manifest ...)).

<gabber>i think `(concatenate-manifests (list (packages->manifest ..) (specifications->manifest ..)))` should work

<wdkrnls>Thanks! that sounds promising. I will give it a try.

<wdkrnls>For completeness, I also tried combining package lists as well with specifications->packages and then trying to turn the combined list of packages into a manifest. I also couldn't get that to work. Maybe there is also a (concatenate-packages ...) procedure as well?

<wdkrnls>Thankfully, I only need one to work.

<gabber>wdkrnls: if you have a list of packages (or strings, doesn't really matter in this case) you can (append) it to another list. you could also (cons* package1 package2 list-of-packages) -- depending on the exact use-case

<wdkrnls>I had a list of packages and then I had the list of strings.

<wdkrnls>Since in practice I was trying to combine some R packages not yet in Guix with packages which were in Guix.

<gabber>i'm not sure this attempt is possible. in guix you can only build (and refer to) packages already packaged in guix

<wdkrnls>It was definitely a revelation to me to read this blog post: https://hpc.guix.info/blog/2022/12/cran-a-practical-example-for-being-reproducible-at-large-scale-using-gnu-guix/

<wdkrnls>It definitely shows that you can put stuff in manifests which are not in Guix defined directly inside your manifest.scm.

<wdkrnls>It just doesn't show that being combined with other packages already in Guix.

<wdkrnls>That is my use case.

<wdkrnls>It is really elegant and I wish I understood it before. Of course, I'm hoping that concatenate-manifest does the trick.

<apteryx>nckx: is there some technical advantage to have /etc/localtime a symlink to a zoneinfo target? or is this just an arbitrary systemd choice that everyone had to blindly follow?

<nckx>That feels like a loaded question in little need of an answer. Why do you ask?

<lechner>i think you are both being a little bit passive-aggressive right now

<lechner>Hi, thanks to jpoiret, is a small Guile script that prints the machine type, if anyone needs it. http://paste.debian.net/1270725

<footlong>"debian Pastezone" http://paste.debian.net/1270725

<gabber>lechner: is that different from the highlighted one in `guix system --list-systems`?

<bjc>apteryx: my freebsd boxen have had /etc/localtime for as long as i can remember; certainly before systemd existed

<lechner>gabber / that's interesting! i thought we had it somewhere, although i concur with jpoiret that it may more properly belong into 'guix describe'. what if someone does not run Guix System?

<lechner>also that really should be called machine-type because a system is bigger

<apteryx>bjc: I asked the folks in glibc, and there's no technical reason other than have the changes propagated in case the zoneinfo package data changes on FHS systems

<apteryx>which doesn't apply to Guix

<apteryx>so it's a bug for libraries/applications such as ICU to to ignore /etc/timezone unless it's a symlink

<nckx>You can certainly try to convince them of that, but it's a widespread assumption these days.

<bjc>are you bothered that it's a symlink, or that it exists at all?

<nckx>I think GNOME does/did the same.

<apteryx>probably GNOME uses ICU, no?

<bjc>also: i'm not aware of an /etc/timezone file, and checking a handful of my systems, none of them have it

<nckx>Probably, but that is not what I meant.

<apteryx>nckx: such as via mozjs

<apteryx>it's already reported ^^'

<apteryx>multiple times it seems

<apteryx> https://unicode-org.atlassian.net/jira/software/c/projects/ICU/issues/?jql=project%20%3D%20%22ICU%22%20AND%20text%20~%20%22localtime%22%20ORDER%20BY%20created%20DESC

<footlong>"ICU - Issues - Unicode Consortium" https://unicode-org.atlassian.net/jira/software/c/projects/ICU/issues/?jql=project%20%3D%20%22ICU%22%20AND%20text%20~%20%22localtime%22%20ORDER%20BY%20created%20DESC

<apteryx>beautiful link

<nckx>apteryx: No, I'm sure GNOME uses ICU, that's not what I meant. I mean that there's a more direct assumption that it can be readlink'd to get the TZ name, for example.

<nckx>apteryx: URL TL;DR.

<nckx>This bot sure is exposing how utterly useless many <title> elements are, jeeze.

<apteryx>in my weechat any URL longer than ~70 chars is utterly useless ^^'

<nckx>Does in not wrap them? Fun.

<nckx>apteryx: I'm still not sure which of those reports you're referring to; which leads me to reading things like <https://unicode-org.atlassian.net/browse/ICU-12543?focusedCommentId=45342> where what you might be complaining about is given as the fix.

<apteryx>yeah they get wapped but being broken on multiple lines with the rest of the UI it's hard to copy paste them

<footlong>"[ICU-12543] - Unicode Consortium" https://unicode-org.atlassian.net/browse/ICU-12543?focusedCommentId=45342

<nckx>Confusing!

<nckx>apteryx: Oh, I understand. I wonder if there's a way to support that at all (is there an ANSI ‘href’ extension?) or if only last-column-wrapped URLs can ever work. Anyway. We drift.

<nckx>Any particular reason you pinged me specifically?

<apteryx>simply because you had commented on the issue last november I think, in my IRC logs, so I thought perhaps you had more details about it

<apteryx>thanks for answering my ping!

<apteryx> https://unicode-org.atlassian.net/browse/ICU-12543 does indeed look like our issue

<footlong>"[ICU-12543] - Unicode Consortium" https://unicode-org.atlassian.net/browse/ICU-12543

<apteryx>(we have both /etc/localtime *and* /etc/timezone, and ICU bails out without even looking at the later)

<nckx>I'm kind of surprised that neither is a symlink here.

<nckx>apteryx: Any time. I have no memory of whatever we discussed (or I said) back then, though, so I'm completely lost on context.

<apteryx>the context was: https://issues.guix.gnu.org/59368

<nckx>What I'm remembering is some component of the GNOME control panel (IIRC) expecting one of them to be a symlink to correctly display the time zone name. Hence my surprise that we never made it one.

<nckx>Thanks.

<footlong>"icecat does not honor /etc/timezone starting with 102.3.0." https://issues.guix.gnu.org/59368

<apteryx>is the requirement for /etc/timezone defined somewhere?

<nckx>footlong: Interesting that you can load that page when I cannot…

<nckx>Ah, I see that I'm repeating myself almost verbatim (I have no memory of typing https://logs.guix.gnu.org/guix/2022-11-14.log#221525) ☺

<apteryx>I'll review "uprv_tzname" from ICU's common/putil.cpp again, this is where the "magic" happens

<footlong>"IRC channel logs" https://logs.guix.gnu.org/guix/2022-11-14.log#221525

<nckx>I vaguely remember poking around IceCat now that you mention it, but it was way too long ago to recall anything useful…

<apteryx>according to the first comment in that bug report, searchForTZFile is supposed to save the day in our situation

<apteryx>I bet it looks under /usr

<nckx>I don't really understand why my Firefox 108.0.2 [yes, I need to update] reports my timeZone correctly.

<apteryx>do you have TZ set?

<apteryx>this gets picked up first

<nckx>I don't think so.

<nckx>I mean, it's not in a shell, I don't think I'm missing a way it's set elsewhere.

<apteryx>OK... interesting. And this is on Guix System?

<nckx>I used to use a ~/.local/bin wrapper which is why I'm being cautious, but I no longer am.

<nckx>Yes.

<apteryx>do you know the ICU version it uses?

<nckx>I was just checking that, but screwed up the command…

<nckx>/gnu/store/b0xl3iqgc7fs68f2kfdyydsdxs77jqph-icu4c-71.1

<nckx>I'm installing Guix's IceCat.

<nckx>But slow link.

<apteryx>ICU's searchForTZFile is called with TZONEINFO as its first arg, which is the directory to search in

<apteryx>which is expanded to /usr/local/etc/zoneinfo/

<apteryx>(*defined as, rather)

<nckx>:)

<apteryx>so patching this to our tzdata package should do the trick?

<nckx>I'd say yes. I'm just a bit distracted by ‘my’ working(?) Firefox. But maybe we're testing different things? I'm checking ‘Intl.DateTimeFormat().resolvedOptions().timeZone’.

<nckx>Now that I understand what you meant by ‘there's no technical reason other than have the changes propagated in case the zoneinfo package data changes on FHS systems’, I still don't agree.

<apteryx>I'm not a fluent javascripter, but yes, I think just a datetime object shows the time wrong

<nckx>First of all, that's an excellent technical reason, no others needed; second of all, do we really have a policy of binding the build-time tzdata this way? (If we do, OK, but the fact that I'm unsure means that it's underdocumented.)

<nckx>apteryx: Could you try that line at the console?

<nckx>Or share yours?

<nckx>I'm even less fluent so ‘a datetime object’ doesn't even mean much to me :)

<apteryx>prints "UTC" in my IceCat console

<nckx>Muh.

<Lumine>Happy "I Love Free Software Day," #guix. :)

<gabber>\o/

<apteryx>nckx: if you input Date(), it shows a the result on the bottom line

<apteryx>says my TZ is GMT+0000 (UTC)

<nckx>Same to you, and all those who celeb—oh wait.

<nckx>apteryx: Nice, that's less typing (or copy-pasting). So IceCat shows UTC, Firefox shows GMT+1.

<nckx>W{ut,hy}.

<apteryx>ah! this is prehaps that way, but there's another local date thing

<apteryx>oh? so you reproduce

<apteryx>hm.

<nckx>OK, no, it was just resistFingerprinting being true (this is a pristine IceCat installation).

<nckx>With it off, I get GMT+1.

<nckx>So it is my environment.

<nckx>I have TZDIR set?

<apteryx>it's set here also

<apteryx>so icecat works for you with resistfingerprinting off?

<nckx>Yes, for the Date() test case.

<apteryx>OK, let me try again, I refreshed my profile yesterday, and it was back on true

<apteryx>for the record, in the next version, there'll be resistfingerprinting.spooftimezone or something as a more fine-grained control

<nckx>I'm sure I have some obvious filth in my environment somewhere, I just can't say what. If IceCat runs in a container I'll see you in half an hour once I figure out the 500 options I'll have to add to guix shell.

<nckx>apteryx: \o/

<nckx>apteryx: Is that an IceCat original feature or FF?

<apteryx>do I have to restart icecat for the resistfingerprinting option to take effect?

<nckx>I did.

<apteryx>FF

<nckx>Nice.

<Lumine>I love how there's really not much you have to modify in terms of the defaults in IceCat, I'm running it right out of the box with its extensions, only one disabled, I think it was the UPS thing which I don't really need.

<apteryx>nckx: still wrong here...

<apteryx>I'll try in a totally new profile

<apteryx>still wrong. my timezone field in my operating-system config is set to "America/Montreal"

<apteryx>what's yours? I'll try reconfiguring for fun

<nckx>First attempt: ‘guix shell --container icecat -E DISPLAY --share=/{tmp,run} --expose=/etc/{localtime,timezone} -- icecat’ — Date() prints UTC.

<nckx>apteryx: Europe/Brussels, bien sur.

<nckx>Is ‘--expose=/etc’ not working a known imperfection?

<nckx>s/known/reported/

<apteryx>I just checked something: md5sum /gnu/store/7pjzwj9d4fnyzp9x7k8cc4hazypyrk0p-tzdata-2022a/share/zoneinfo/America/Montreal and md5sum /etc/localtime agree (44a2dd3cb61b90aa4201c38e571a15ba)

<apteryx>nckx: the closest thing to your expose bug I can find is #46782

<apteryx>I thought we solved this with recursive bind recently (added by rekado)

<nckx>That is indeed what it reminded me of!

<nckx>Thanks.

<nckx>apteryx: Do you get a Guix mkstemp error with ‘guix shell --container icecat -E DISPLAY --share=/{tmp,run,etc} -- icecat’?

<apteryx>yes

<nckx>Ta.

<apteryx>it comes from --share=/etc

<apteryx>I'll try in a VM

<oleander>Hello, alacritty is not displaying some characters correctly on my system (? instead of €). I'm using the DejaVu Sans Mono font. Does this have to do with Guix or my terminal? I get the same behavior with Kitty and Foot.

<nckx>Sounds like non-UTF-8 or other locale issue. Almost certainly not font. Are you using a locale that ends in ‘.utf8’? Is this a Guix System?

<nckx>ACTION hungrily goes AFK though.

<apteryx>nckx: funny, I wonder if TZDIR as an environment variable is common

<gabber>apteryx: it is present on my Guix system

<apteryx>because if it is, one could argue that ICU should honor $TZDIR and fall-back to its own TZDIR definition (currently: "/usr/local/etc/zoneinfo")

<apteryx>ACTION checks the icu bug tracker again

<nckx>I think that's a great solution even if it's not numerically ‘common’.

<oleander>nckx: yes it's guix system and I'm using this locale: (locale "en_US.utf8")

<qzdlns[m]>o/

<nckx>ACTION starts downloading a gigglebyte of glibc-locales, and goes AFK again.

<apteryx>nckx: I can reproduce using: https://paste.debian.net

<apteryx>(in guix system vm)

<apteryx>to fire a console in ratpoison: 'C-t c'

<nckx>apteryx: I'm gonna be away for a while, but just FYI, that link's a bit generic 😉

<apteryx>ah! https://paste.debian.net/1270735/

<nckx>I… guess this isn't spam? <https://paste.debian.net/plainh/2969b67a> Don't be cross with me for approving it :3

<nckx>o/

<n1tram1>hello, I'm currently building a system image, is there a way to get some live output/logs from the derivation build ? (linux-libre has been building for a while, I'd like to see what it is up too ^^)

<unmatched-paren>afternoon guix :)

<apteryx>we have #:disallow-references, but do we have #:ensure-references? :-)

<apteryx>hm, we have allowed-references, but that's just a "that may be referenced"

<apteryx>nckx: I'm rebuilding icecat with a fixed icu4c@71

<apteryx>this could go to master

<apteryx>bah, it didn't work

<dominicm>where is the log for guix's ssh daemon? it doesn't seem to be in /var/log

<puddinghead>hey, i've been trying to use guix as a package manager in devuan recently

<puddinghead>however, when i install a package, i can only use it in the same terminal window i ran guix install for it on, and if i open another terminal window, or restart my system i cant use it again unless i remove the package and install it again

<puddinghead>i have set up my enviroment variables both in the terminal itself and in .bash_profile as GUIX_PROFILE="/var/guix/profiles/per-user/parappa/guix-profile"

<lechner>puddinghead / Hi, it is probably limited to that shell

<puddinghead> . "$GUIX_PROFILE/etc/profile"

<puddinghead>why is it?

<puddinghead>i've tried in both bash and fish and it is indeed limiting itself to that shell

<lechner>most Guix executables rely on environment being set up in a particular way to find prerequisites

<unmatched-paren>puddinghead: pretty sure GUIX_PROFILE should be ~/.guix-profile

<puddinghead>ooh

<unmatched-paren>might fix it, might not :/

<puddinghead>it wont

<puddinghead>because i had to create that one myself in order to limit the amount of locales id like to have

<puddinghead>i installed guix through the installer scripy

<lechner>puddinghead can you start a new shell and source the profile from there?

<lechner>new window is best

<lechner>Hi, were in the Guix source tree does 'guix repl' determine whether stdin is a terminal, please?

<puddinghead>ok, but first, how do i source the profile?

<puddinghead>when i load guix repl i get the following

<puddinghead>Enter `,help' for help.

<puddinghead>scheme@(guix-user)> stdin

<puddinghead>;;; <stdin>:1:0: warning: possibly unbound variable `stdin'

<puddinghead>ice-9/boot-9.scm:1685:16: In procedure raise-exception:

<puddinghead>error: stdin: unbound variable

<puddinghead>Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.

<puddinghead>scheme@(guix-user) [1]>

<unmatched-paren>puddinghead: please use paste.debian.net for large amounts of text

<unmatched-paren>to source the profile:

<unmatched-paren>. "${GUIX_PROFILE}/etc/profile"

<nckx>Compiler authors: We spent innumerable hours adding friendly error messages and ASCII-art to our newest release, we hope you like it :3

<nckx>Compiler users: https://paste.debian.net/plainh/0b38af73

<puddinghead>thanks a lot unmatched-paren

<puddinghead>ok, bash says that my profile is /home/username/.config/guix/current

<nckx>lechner: To what end? Whatever you're looking for is going to look something like https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ui.scm#n1726

<rice-crispies>"ui.scm\guix - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ui.scm#n1726

<puddinghead>and then . /etc/profile/etc/profile

<puddinghead>no such file or directory error

<nckx>Not aware of a non-open-coded (for low values of ‘open coded’ TBH) version.

<unmatched-paren>puddinghead: there are actually two default profiles (three on Guix System)

<jlicht>hey guix!

<nckx>puddinghead: Are you the one entering ‘stdin’ into that REPL?

<unmatched-paren>the user profile (~/.guix-profile, stores packages and stuff), the guix profile (~/.config/guix/current, stores guix itself), and the system profile (/run/current-system/profile, stores the Guix System system profile

<unmatched-paren>)

<nckx>jlicht: o/

<unmatched-paren>so you need to source both of the former two

<puddinghead>i see

<puddinghead>so do i need to do that in repl?

<puddinghead>i actaully exited the repl to get that

<unmatched-paren>no, in the shell

<puddinghead>yeah im in the shell rn

<unmatched-paren>these are all shell commands :)

<unmatched-paren>you don't operate Guix from the repl typically

<cbaines>I've just restarted mumi on berlin

<cbaines>it seemed to not be working

<puddinghead>so

<puddinghead>whatever i get when i load . "${GUIX_PROFILE}/etc/profile"

<jlicht>cbaines: you touched it last now ;)

<puddinghead>that's my sourced profile then

<unmatched-paren>puddinghead: what does ${GUIX_PROFILE} contain?

<unmatched-paren>as in, what's the text in the variable?

<puddinghead>it contains /home/username/.config/guix/current. which is a directory

<unmatched-paren>can i see your ~/.bash_profile and ~/.profile?

<nckx>puddinghead: How did you install Guix on this system?

<GNUtoo>Hi, for some strange reasons the same Guix 1.4 installation script works on x86_64 but not on i686

<nckx>Ruh roh.

<GNUtoo>oops

<GNUtoo>Hi, for some strange reasons the same Guix 1.4 installation script works on x86_64 but not on armhf

<GNUtoo>on armhf I get "The certificate has expired"

<nckx>Does this board have a (correctly set) RTC? :)

<GNUtoo>yes: Tue Feb 14 19:06:36 CET 2023

<jlicht>cbaines: the issues.guix.gnu.org website works for me now, fwiw

<nckx>GNUtoo: Damn it, you stole my favourite fruit. Do you know which URL/line/command is to blame?

<GNUtoo>Maybe it's an issue with the machine rootfs though as "wget https://ftp.gnu.org/gnu/guix/ --no-verbose -O-" fails

<nckx>If both machines have a very different OS, the OS root cert package might be outdated.

<GNUtoo>yes, I'll try to fix that

<puddinghead>here's my bash_profile

<puddinghead> https://paste.debian.net/1270750/

<rice-crispies>"debian Pastezone" https://paste.debian.net/1270750

<puddinghead>and here's my regular profile on the debian pastezone https://paste.debian.net/1270751/

<rice-crispies>"debian Pastezone" https://paste.debian.net/1270751

<puddinghead>i installed guix through the command line shell script for it

<lechner>nckx / from #guile Hi, open-pipe* inherits the caller's current-*-ports. Is that the right behavior? Called programs locally believe they are talking to a terminal https://www.gnu.org/software/guile/manual/html_node/Pipes.html

<rice-crispies>"Pipes (Guile Reference Manual)" https://www.gnu.org/software/guile/manual/html_node/Pipes.html

<jpoiret>lechner: it's expected yes

<jpoiret>if you need to redirect all stdout/in/err you probably need the new spawn

<puddinghead>what should i change in my .bash_profile and .profile files then?

<lechner>jpoiret / guix repl gives me the copyright notice when called to evaluate %system

<jpoiret>lechner: are you using the `guix repl -- file` method?

<jpoiret>if you're just piping to a bare `guix repl` that's what you'd get

<lechner>jpoiret / no, i am trying to use (open-pipe* OPEN_BOTH)

<jpoiret>can you send a snippet of your code?

<lechner>jpoiret / well, here is what works http://paste.debian.net/1270752

<rice-crispies>"debian Pastezone" http://paste.debian.net/1270752

<puddinghead>i noticed that the directory that i had in my .bash_profile's GUIX_PROFILE directory aand the one that actually came up when i loaded ${GUIX_PROFILE} were different

<puddinghead>so i changed my .bash_profile's directory to the same i got when I loaded ${GUIX_PROFILE} - is that a good way to go?

<lechner>jpoiret / this does not presently work, although on other occasion, i have been able to get the string "GNU Guile 3.0.9" http://paste.debian.net/1270754

<rice-crispies>"debian Pastezone" http://paste.debian.net/1270754

<lechner>jpoiret / sorry that should look more like this http://paste.debian.net/1270755

<rice-crispies>"debian Pastezone" http://paste.debian.net/1270755

<jpoiret>rightttt, that's the difference. You should use "guix" "repl" "-q" "--" "/dev/stdin" as the command line

<jlicht>Would anyone with more CPU cycles than good sense be able to locally build #59188? QA hasn't picked it up, but it Works On My Machine (tm)

<rice-crispies>"[PATCH 0/4] gnu: node-lts: Update to 18.12.1." https://issues.guix.gnu.org/59188

<jonsger>PATCH v3 0-16?

<jpoiret>jlicht: you could probably ask cbaines for some help unblocking that on QA

<jpoiret>there's a cap on how many new derivations can be built by a patchset iirc

<parappa>i changed my .bash_profile to direct GUIX_PROFILE to the value i get on ${GUIX_PROFILE}

<parappa>but i still cant open up apps ive already installed after closing the shell i installed them on

<parappa>even though i have them installed

<jlicht>cbaines has plenty of good sense though :). It would be appreciated indeed if it somehow can still be scheduled though

<jlicht>jonsger: yes!

<jonsger>jlicht: do you have a git branch of them?

<nckx>parappa: Did you also source "${GUIX_PROFILE}/etc/profile" afterwards? Simply setting GUIX_PROFILE does absolutely nothing on its own.

<jlicht>jonsger: I do not, just the patch series

<nckx>parappa: But installing Guix through guix-install.sh will create an /etc/profile.d drop-in, which most major distroes source through /etc/profile, which should do all this for you. Manually adding things to ~/.* files doesn't exactly void your warranty, but it is a ‘we'll now assume you know what you're doing’ move.

<lechner>jpoiret / this illustrates the problem (but also shows a pipe error that demonstrates my lack of Guile skills) http://paste.debian.net/1270757

<rice-crispies>"debian Pastezone" http://paste.debian.net/1270757

<lechner>actually, that error comes from inside 'guix repl'

<puddinghead>oh so i also have to source ${GUIX_PROFILE}/etc/profile" then

<nckx>'t Would help.

<puddinghead>how do i have to do it

<puddinghead>because just tyoing it in doesnt really give me anything

<nckx>puddinghead: Do you have a ~/.guix-profile symlink?

<puddinghead>nope, had to create that folder myself

<puddinghead>what should i do then

<puddinghead>clean reinstall of guix and try to do things right this time around?

<nckx>puddinghead: Hm, ‘folder’? Did you create it as a symlink to /var/guix/profiles/per-user/parappa/guix-profile?

<nckx>If you just used mkdir or whatever, I think you'll encounter (more) weirdness.

<nckx>puddinghead: Well, I asked you how you installed Guix above, if you answered it I've missed it…

<nckx>puddinghead: Is there a file in /etc/profile.d with ‘guix’ in the name?

<attila_lendvai>something is wrong with my fontconfig. one issue is that firefox opens an xml file, renders it properly, but when trying to print it into a pdf then the font in the pdf is unreadable (some 4 pixel size chars enlarged -- super pixelated). any hints where i could start debugging this?

<attila_lendvai>i don't have anything specific/unusual wrt font config, pretty much the defaults and some extra fonts installed. but i think it began when i started to use guix home.

<nckx>ACTION AFK.

<mfg[m]>I'm looking at the serviec documentation for opensshd and can't seem to find an option to disallow password login. Am i blind or is there actually no such option at the moment?

<attila_lendvai>mfg[m], i do have a password-authentication? field

<attila_lendvai>mfg[m], not in the docs, but in the code, that is.

<nckx>It's documented under ‘Network Services’.

<nckx>puddinghead: Could you share your /etc/profile if you haven't yet? For some reason I can't read the logs (local problem, I'm positive).

<mfg[m]>attila_lendvai: Ha, thanks :) nckx: the manual doen't reference this and only has 'extra-content' as a raw string.

<mfg[m]>i'm looking at the devel manual

<acrow>mfg: Not sure but maybe that is now a pam issue.

<mfg[m]>acrow: what do you mean?

<jonsger>jlicht: sorry can't apply it on current master. If you give me a git branch, I'll have a look otherwise not...

<puddinghead>sorry for not responding earlier, was afk because i had to eat but

<puddinghead>@nckx Hm, ‘folder’? Did you create it as a symlink to /var/guix/profiles/per-user/parappa/guix-profile?

<puddinghead>i used mkdir for it

<puddinghead>and i installed Guix through the shell script rather than the apt package or manually

<puddinghead>/etc/profile.d DOES have a file named guix, more especifically guix.sh

<puddinghead>i dont use irc very often so sorry if it doesnt sound like im following irc syntax

<unmatched-paren>irc doesn't have any syntax :)

<puddinghead>nice, i just wondered hows to like refer to a user when sending a message

<nckx>You're fine :) No need for ‘@’ but nor does it hurt, and you've learnt the most important cultural norm (use a paste service).

<unmatched-paren>yeah, you can just write the name: "this message will ping puddinghead"

<nckx>Any good client highlights the name, simply whenever it occurs in a message. There is no special ‘user’ syntax.

<nckx>Too late.

<puddinghead>thanks for the guides nckx

<unmatched-paren>wait, "username = highlight" isn't inherent to IRC?

<puddinghead>and wdym with too late

<nckx>Some people configure their clients to only ping when it's the first word, or followed by a ‘:’, but you should not feel obligated by that.

<nckx>puddinghead: I just meant that unmatched-paren had said the same thing with fewer words.

<puddinghead>oh, really?

<puddinghead>i might have missed it since i was afk for a few minutes

<juli>hello guix comrades. (guixes? guixers? what is our demonym?) i am endeavoring to package dino 0.4 but pkg-config can't seem to find libadwaita despite it being on `PKG_CONFIG_PATH`. i suspect the crux of the issue is the custom script being used to find it: https://github.com/dino/dino/blob/master/cmake/FindAdwaita.cmake the error message being: https://pastebin.com/EGAdyR4Y

<rice-crispies>"dino/FindAdwaita.cmake at master · dino/dino · GitHub" https://github.com/dino/dino/blob/master/cmake/FindAdwaita.cmake

<rice-crispies>"CMake Error at /gnu/store/j65q3aw414010gdfvmsynwpzfb2jyyd3-cmake-minimal-3.21.4/ - Pastebin.com" https://pastebin.com/EGAdyR4Y

<nckx>unmatched-paren: There is no ‘highlight’ concept in the protocol, no. Just lines of text. Your client runs a text search, or doesn't. Most clients can be configured to ping on whatever random list of words you like (or don't).

<attila_lendvai>FTR, if i turn off "Allow pages to choose their own fonts, instead of your selections above" in firefox, then the print-to-pdf font issue is gone

<puddinghead>i see

<puddinghead>so for now i should just uninstall guix, reinstall and try to set up again without any confusion right?

<puddinghead>or can i salvage my current install

<unmatched-paren>puddinghead: your system should be sourcing /etc/profile.d/guix.sh

<puddinghead>i see

<puddinghead>and what should i do to source it then

<unmatched-paren>it should be sourcing *everything* in /etc/profile.d iiuc

<puddinghead>yeah it should

<unmatched-paren>regardless of the name

<nckx>Yeah, sorry, I got sidetracked by IRC nonsense :) Reinstalling won't really change much. But, the installer does assume that /etc/profile sources everything in /etc/profile.d. Many distroes do this.

<puddinghead>how do i check its sourcing

<puddinghead>yeah im in devuan and it does it

<acrow>mfg: I mean that opensshd is not doing authentications by password that is a system responsibility and, I think, it is delegated through your PAM configuration. So, openssh is not where you would go to disable it.

<nckx>That's why I asked for the contents of /etc/profile earlier.

<puddinghead>havent checked /etc/profile sadly

<nckx>puddinghead: Have you logged out & back in yet? /etc/profile is only sourced at log-in, by design.

<puddinghead>yeah ive had, multiple times

<nckx>Oh, also fix that mkdir → ln first :)

<puddinghead>oh ok

<puddinghead>so heres my /etc/profile

<puddinghead> https://paste.debian.net/1270762/

<rice-crispies>"debian Pastezone" https://paste.debian.net/1270762

<puddinghead>and ive now deleted the .guix-profile directory

<puddinghead>now what do i do to symlink

<nckx>OK, line 27 does what we expect. As we'd expect from a Debian fork.

<nckx>/var/guix/profiles/per-user/parappa/guix-profile

<nckx>The /etc/profile.d snippet tests for the existence of ~/.guix-profile *and* that it's a symlink. It wasn't in your case, so it never sourced that profile's etc/profile file (what a sentence). That's what went wrong.

<nckx>I hope :)

<nckx>It's weird that ~/.guix-profile wasn't created since you said you ‘guix install’ed something?

<Guest63>is it possible to install grub on btrfs? I tried installing guix using the installer and partioned a 1GB btrfs partition but it says this gpt partition label containers no bios boot partition

<nckx>Or did I hallucinate that? (Still no logs, I'm behind some weird IRC-only firewall, wtf…)

<unmatched-paren>yeah, they said that

<nckx>Thanks.

<nckx>So that's weird.

<unmatched-paren>but maybe they tried to mkdir before they did that?

<nckx>Ah, possible!

<nckx>A timing attack :)

<puddinghead>nckx thats becouse i created it before guix installing something lol

<unmatched-paren>There we go.

<nckx>Guest63: This error has nothing to do with btrfs, but with booting a GPT-partitioned drive on a non-UEFI (‘BIOS’ or ‘CSM’) system.

<puddinghead>used mkdir so i could set up locales

<unmatched-paren>um, how does that help you set up locales? :)

<nckx>You need to create a tiny (1MB is more than big enough) partition and mark it as ‘BIOS boot partition’ in your tool.

<nckx>You don't need to do anything more to it. Guix will run GRUB which will find it and use it.

<Guest63>ah thanks

<Guest63>how can I mark it as bios boot partition in the installer?

<nckx>I'm afraid I don't know that part, sorry.

<nckx>I don't… use it…

<Guest63>because it seems to me this isn't possible. not much documentation of it either

<nckx>That would be one problematic oversight.

<Guest63>1mb btrfs is ok for boot partition?

<nckx>I'm weary why you mention ‘btrfs’. Because you don't need a file system on it at all.

<Guest63>i set it to 1M and btrfs yelled at me it is not large enough to create a fs

<Guest63>well I just looked what guided did and replaced ext4 with btrfs to be honest

<nckx>The problem is those will all (1) create a file system, which at best we don't care about (and at worst will error out like btrfs) (2) set the type to ‘Linux file system’, not ‘BIOS boot partition’, which is important.

<nckx>I'm familiar only with manual installations & (c)fdisk…

<nckx>I'm downloading the installer ISO now.

<Guest63>okay, i`ll wait for you

<nckx>This will take a while, since it's through an SSH tunnel, because the gods hate me.

<Guest63>btw I can't use uefi as well as I nstall it in a vm

<nckx>I really hope the answer is not ‘this is missing from the installer’.

<Guest63>sure, no problem

<nckx>Your VM software doesn't support UEFI?

<Guest63>well, i use the Guix one

<puddinghead>unmatched-paren

<puddinghead>its because you can use guile to set up what locales you want to actually use for guix packages

<puddinghead>or so it says in the documentation

<nckx>Guest63: If UEFI is not an option, is choosing ‘MS-DOS’ (not GPT) partitioning an option?

<nckx>Guest63: That would sidestep this issue.

<puddinghead>i dont think it really does much if you use guix as a package manager rather than as your distro

<Guest63>yes, I can change the whole disk to either msdos or gpt

<unmatched-paren>puddinghead: where does it say that?

<unmatched-paren>locales are controlled with LC_ALL, LANG, et al, no?

<nckx>Is there a specific reason you chose gpt over msdos? If not (or if it was just ‘it's modern’, which is true :), use msdos. 128 partitions is handy but probably overkill for a VM.

<Guest63>puddinghead: try to get tpm2 and uefi working, since this does not work out of the box but on other distros it does

<puddinghead>unmatched-paren guix reference manual, 2.6 application setuo 2.6.1 locales

<nckx>ACTION is downloading an ISO over DNS at ~50KiB/s; 2023 sucks.

<unmatched-paren>puddinghead: ah. i think you may have misunderstood that section.

<mfg[m]>acrow: well it is, in plain openssh it is the option PasswordAuthentication in guix it's the field password-authnetication? i set if to #f and now i can't login via password anymore, exactly as it should. I don't see where pam is supposed to interfere here, but i also no not much about pam.

<mfg[m]>s/no/know

<puddinghead>Guest63 I'm running guix as a package manger on top of Devuan, not the distro

<Guest63>nckx: System is installing with msdos, will find out if it works in ca. half an hour

<puddinghead>unmatched-paren as i expected, given my lack of experience with lisp and enviroment variables beyond copying and pasting sysctls

<nckx>mfg[m]: I missed your earlier message. Uh, the manual definitely mentions ‘password-authentication?’, I'm looking right at it. Could you check your local info manual rather than the Web site, just to make sure I'm not going loopy?

<nckx>Guest63: Good luck. May you not get other errors :)

<Guest63>puddinghead: Me, too. Host is Gentoo. With Gentoo I can just install virt-manager and the packages "tpm2-tss" and "ovmf". This will result to a working out of box vm with uefi and tpm2 emulated module. Now on Guix it is possible but I need to do some configuration. No clue what exactly I need to do. Usually you just need to install the

<Guest63>packages but that is not how Guix works.

<puddinghead>yeah, i can see why

<puddinghead>tahts why im personally planning to not use guix for stuff like virtualization

<puddinghead>just regular desktop programs with select compilation flags to avoid dependency hell

<puddinghead>anyways i del;eted the mkdir crated .guix-profile

<puddinghead>now to see if it automatically generates the folder

<unmatched-paren>Guest63: by design, packages do not affect the system itself

<Guest63>I am going full in. Sure at the beginning it will be pain but after some time I understand how everything works as well as learn scheme

<unmatched-paren>to do that, you need a service in your config.scm

<nckx>I run QEMU on Guix System with ‘-bios $(guix build ovmf)/share/firmware/ovmf_x64.bin’, which is good enough for me, but this could probably be made more seamless if someone would dedicate time to it.

<Guest63>I use Virtual Machine Manager. Never did use qemu directly to be honest

<nckx>Can't speak for libvirt/virt-manager/… which is too heavyweight for my own uses.

<nckx>Surre.

<nckx>*Sure.

<mfg[m]>nckx: yes, i did look online. In the info manual everything seems alright. I don't use info though. Can't remember how to properly navigate and search it...

<mfg[m]>maybe i should learn it

<mfg[m]>should save quite some time

<puddinghead>okay, just guix pulled

<mfg[m]>iguess

<nckx>mfg[m]: Phew, thanks for the confirmation.

<puddinghead>no .guix-profile folder has been created

<nckx>puddinghead: It wouldn't. Only installing a package (NOT guix) would.

<puddinghead>given all this setup just to be even able to load a asimple textoh ok

<puddinghead>sorry for the message

<puddinghead>just wanted to say ok

<Guest63>I wonder, how $(guix build ovmf) works. Is it that Guix actually builds but it sees it is already build and therefore prints out the path of the already build package?

<unmatched-paren>Guest63: Precisely :)

<nckx>puddinghead: Busted! Meh, it's not entirely unwarranted. There is plenty of room for UX improvement. Nobody will deny that.

<puddinghead>removed a pacakge, it worked!

<unmatched-paren>puddinghead: guix pull downloads the latest version of guix into ~/.config/guix/current, *not* ~/.guix-profile :)

<Guest63>unmatched-paren: thansk

<Guest63>thanks*

<puddinghead>i see, thanks!

<nckx>Guest63: It does both: builds/downloads it if it's missing, then later invocations print the existing file name relatively quickly.

<Guest63>What exactly prevents Guix from having a fancy GUI installation?

<puddinghead>was about to say that it finally worked

<nckx>Guest63: Persons * time.

<puddinghead>except that i had to set up the guix profile command i got with the hint after resinstalling the text editor on the shell

<Guest63>nckx: Is it hard or could I as a beginner work on it?

<unmatched-paren>Guest63: Well, it depends.

<puddinghead>i have to set these enviroment varaibles every time i run the shell apparently

<nckx>puddinghead: I don't think so?

<unmatched-paren>puddinghead: you need to add them to ~/.profile if they aren't already there

<puddinghead>yeah i added them to .bash_profile

<nckx>Which variables?

<puddinghead>which means that ill only need to do so manually until i log out or restart

<puddinghead>nckx the GUIX_PROFILE variables

<nckx>Are you sure, unmatched-paren? Adding them to a file is a common mistake.

<nckx>The message I'm thinking of says no such thing.

<unmatched-paren>Guest63: If you write it in Scheme, it shouldn't actually be hard at all, since Guix is just a massive Scheme library with a script that essentially does 'import guix-stuff' and then 'guix-stuff.run-guix' :)

<Guest63>that variable is not saved on my side

<unmatched-paren>nckx: ohh, yeah, of course

<Guest63>I only have GUIX_LOCPATH=$HOME/.guix-profile/lib/locale, "$HOME/.guix-profile/etc/profile", "$HOME/.config/guix/current/etc/profile"; isn't GUIX_PROFILE automatically done?

<unmatched-paren>you don't add them to the file, that's just a stopgap until you log out

<efraim>error message from compiling gcc: ar: unable to copy file '.libs/libstdc++.a'; reason: Success

<nckx>Note that I'm not a foreign distro expert; feel free to correct me if needed. I'm just sceptical :)

<nckx>efraim: \o/

<puddinghead>nice

<puddinghead>now im gonna try logging out so i can see if the changes do apply now

<unmatched-paren>Guest63: If you write it in another language, it might be technically possible, since Guile is similarly a massive C library...

<Guest63>unmatched-paren: I am not an expert in this field but Scheme would be the best choice or not?

<Guest63>I mean it is just a GUI not a video game

<Guest63>C and Scheme are the system languages of a GNU System. Therefore Scheme is the best choice or not?

<unmatched-paren>sneek: later tell puddinghead: you only need to do that when there's a new 'search path' (environment variable such as PATH or EMACSLOADPATH)

<sneek>Got it.

<nckx>sneek: later tell puddinghead: The environment variable dance is far from ideal, but it's harder to solve than some newcomers think. Basically, any way (that we can think of) for ‘guix install’ to affect the environment surrounding it (the shell, the terminal, the desktop) would be *extremely ugly* and fragile.

<sneek>Got it.

<nckx>Poor puddin' going to get spammed.

<unmatched-paren>Guest63: Scheme by *far*.

<unmatched-paren>For the aforementioned reason that Guix is a huge Scheme library with a script that essentially calls a 'do-guix-stuff' procedure.

<efraim>oops, typo in my tar fix on core-updates. instead of skipping the broken test I only ran the broken test

<nckx>Saves time.

<unmatched-paren>But it would be technically feasible to do it in any language with a C FFI, as Guile can be used from C via libguile...

<unmatched-paren>If you were to choose to do that... well, I wish you luck. Have fun >:)

<Guest63>unmatched-paren: Okay, well I need to get comfortable with Guix and learn Scheme as well how to do it the GNU way but after some time I could work on that. That installer looks outdated and people should net get that impression

<unmatched-paren>Guest63: Ah, so you're talking about adding a GUI installer?

<Guest63>yes

<Guest63>you know like every other distro, booting a live environment and run the installer

<unmatched-paren>ah, doing a live environment would probably be quite involved

<unmatched-paren>probably possible though.

<unmatched-paren>Debian actually has a non-live GUI installer. It's just a full-screen GUI that doesn't run on top of any desktop.

<nckx>The current installer is a live environment, JSYK. You can switch terminals and do whatever you like without ever using the installer. But it's not graphical, true.

<Guest63>well to be honest, Debian has a more user friendly installer if you ask my opinion

<unmatched-paren>It would be cool to have a full-screen installer like that Debian one that runs in TTY1.

<nckx>We would perform certain frowned-upon acts to have the Debian team's size, resources, and history.

<Guest63>nckx: Do you know how long it takes till the ISO is downloaded?

<Guest63>Sure, but it is also important that people even start with it and talk about it

<puddinghead>just restarted, and i can indeed load programs now!

<sneek>puddinghead, you have 2 messages!

<sneek>puddinghead, unmatched-paren says: you only need to do that when there's a new 'search path' (environment variable such as PATH or EMACSLOADPATH)

<sneek>puddinghead, nckx says: The environment variable dance is far from ideal, but it's harder to solve than some newcomers think. Basically, any way (that we can think of) for ‘guix install’ to affect the environment surrounding it (the shell, the terminal, the desktop) would be *extremely ugly* and fragile.

<nckx>Guest63: Here? Extremely long, probably uselessly long.

<puddinghead>yay, and yeah i agree wit the enviroment variable dance being hard

<nckx>See my grumbling about DNS above. It's currently up to a whopping ~70 KiB/s.

<puddinghead>i guess i wont deal with it unitl i really have to

<nckx>Well, once you have a few packages installed it will be rare.

<nckx>Going from 0 search paths to some is the biggest bump.

<puddinghead>yeah, i already have a few packages such as locale, fonts for gui applications and neovim installed

<Guest63>nckx: 50kB would take 4 hours 31 minutes (814M is the size of the ISO on my disk)

<nckx>Those will set up most. (Search paths are the Guixy name for most environment variables like EMACSLOADPATH, C_INCLUDE_PATH, etc.)

<nckx>Guest63: That sounds about right.

<unmatched-paren>I suppose if there was a Wayland library for Guile [I don't think there is yet :'(] it would be pretty easy to just run <https://www.hjdskes.nl/projects/cage/> and then implement a wayland client in (guix installer) that's run in that cage instance

<puddinghead>also, since i have guix as a packaga manger, are there any packages im better off installing from my distro's native package manager instread?

<puddinghead>i know drivers are a no-no, but what about process managers such as -top style apps

<unmatched-paren>"[Cage] displays a single maximized application at a time and prevents the user from interacting with anything but this application.

<unmatched-paren>puddinghead: pretty much everything should work, so long as it's not integral to the system

<puddinghead>oh, i see

<unmatched-paren>the tops should work fine

<Guest63>puddinghead: Well thinks that require services like virt-manager (libvirtd)

<unmatched-paren>for instance, you don't want to install the kernel via guix :P

<puddinghead>yeah im def not installing that from guix

<puddinghead>the kernel is already too exaggerated

<puddinghead>i also want to mantain a package on guix

<puddinghead>this is because ive seen its not updated on guix but it is in other distros, because the devs do not mantain its package on guix

<nckx>puddinghead: I'm going to start bowing out of this discussion about foreign distroes, but IME/IMO terminal things like htop and friends should be a very safe bet, and it's actually the fancy ‘non-system’ stuff like Web browsers &c. that can sometimes lead to problems.

<Guest63>nckx: If you do not use the installer to install Guix System, how do you do it then?

<puddinghead>nckx seems legit, web browsers 1000 years to compile!

<Guest63>also I see that Guix does not have a maintainer list. I wonder if that thing is planned. Like for example if you go to a package you see the persons name that takes care of that package

<nckx>Oh, I didn't mean that (although it's true). It's more about environment variables mucking about with your host distro's desktoppy stuff (‘desktoppy stuff’ is insanely complex). Any ‘low-level’ text tool that isn't a literal kernel driver will actually be much more likely to work.

<puddinghead>yep, just installed btop on guix

<puddinghead>and i dont need sudo to kill processes at all!

<unmatched-paren>Guest63: to summarise: you could probably build a fairly decent graphical installer with a silly fullscreen wayland compositor consisting of (hypothetical guile-wayland + guile-cairo + xkbcommon + whatever library does mouse input) on top of cage

<nckx>Guest63: I use command-line tools like (c)fdisk, mkfs.whatever, etc., then finish off with scp and/or git and/or emacs to get a system.scm that I can give to ‘guix system init’. Installation isn't that complex once you're very familiar with Guix.

<nckx>IMO, although it's a fine piece of software, there's no advantage to using the installer at that point. Nor would it hurt. It's preference.

<Guest63>nckx: Does a guix system init not require an already installed OS?

<unmatched-paren>sneek: later tell puddinghead: package writing is pretty straightforward under guix :)

<sneek>Got it.

<unmatched-paren>Guest63: you can do that in a terminal under the live image

<Guest63>unmatched-paren: Honestly it takes some time to reach to the point that I will work on that. Things will be different in let's say 6 months.

<unmatched-paren>(in the image, tty1 provides the installer, tty2 the manual, and the rest a bunch of terminals)

<Guest63>ah got it

<Guest63>never figured that stuff out

<puddinghead>yeah

<sneek>puddinghead, you have 1 message!

<sneek>puddinghead, unmatched-paren says: package writing is pretty straightforward under guix :)

<puddinghead>nice!!!

<nckx>Guest63: We are trying to scale without having per-package maintainers. Maybe that will prove impossible, but I see no evidence that our current growing pains are due to a lack of per-package maintainers and not the myriad more obvious shortcomings. We do have ‘teams’ that provide advice, mentorship, and hopefully a bit of institutional knowledge about subject areas. Those are quite new and still being implemented.

<juli>writing packages is pretty straightforward under guix compared to other PMs unless you have non-standard build processes or need to touch the network*

<puddinghead>its a matrix client so itll def touch the network lol

<juli>(although i personally think if your build process needs the network you've mucked up)

<nckx>puddinghead: But building it shouldn't, generally.

<unmatched-paren>Ah, yes, I forgot about the caveat emptor in the case of "Ultra Enterprise Hyper-X Nova Auto-Builder(TM)".

<nckx>Tru.

<nckx>I've developed a phobia of E-Z-build™ ‘building X is simple! Just run ‘fooblorp build’!!!’ projects. They are, invariably, shit.

<unmatched-paren>Sorry, I mean "Apache(R) Ultra Enterprise Hyper-X Nova Auto-Builder(TM)".

<nckx>Guest63: It requires a running OS with Guix, nothing more. The target partition can be, and generally is, empty.

<juli>anyway i'm guessing this means no one knows how to make this weird bespoke cmake script find libadwaita lol

<puddinghead>i see

<Guest63>nckx: Okay it is nearly finished copying mnt. I just want to try Guix System with BTRFS and a seperate /home partition in a VM before I go bare metal. If you have any advice how to install that stuff smarter go for it. Especially I am new to BTRFS and Guix System. (I did some reaserach on BTRFS but they never show you how to set it up)

<puddinghead>to be honest the main reason why i even want to mantain the package is because from what it seems updates dont come in fast enoiugh to guix

<puddinghead>last time i remember the guix package for it was a whole version behind the upstream release

<unmatched-paren>nckx: (define (build-system-evil? build-system) (string-contains-ci (build-system-description build-system) "download"))

<jpoiret>updates don't just come magically in guix though

<nckx>Guest63: A separate /home partition is as easy as making one and adding it to your OS's file-systems list. I think Guix support subvolumes just fine with (options "subvol=foo"), but this is not something I have personal experience with.

<puddinghead>yeah, tahts why im deciding to start mantaining the package on guix

<unmatched-paren>Usually all you need to do is change the version field and the SHA256 hash of the source, though.

<Guest63>If I understand it correctly the only reason they are outdated is because no one is updating them. Other than that they should always be the latest

<jpoiret>that's true, but still, someone has to do it :)

<puddinghead>oh, it finally updated? nice

<juli>iiuc there are no formal "package maintainers" in Guix. is this something that should/could be changed?

<puddinghead>i guess that means i wont have to step up to do it until a new version gets released again

<jpoiret>Guest63: although note that some updates might require changing the package definition more than just its version field

<puddinghead>yeah, theres no formal package managers in guix fro mwhat it seems

<puddinghead>makes me wonder how packages are even updated sometimes

<nckx>We are all responsible for all packages.

<puddinghead>thats cool

<juli>I love communism.

<jlicht>our 29.X versioned emacs-next self-reports as GNU Emacs 30.0.50 :O

<jpoiret>jlicht: i mean emacs 29 is the current stable right?

<puddinghead>gnu/communism

<jlicht>jpoiret: Is it? I thought we were still at 28

<Guest63>I will package like 4 packages as well and try to maintain them. One of it gets updates nearly every day or two. I guess it would be better to make a commit once a week instead of spamming it?

<nckx>puddinghead: That's not perfect, and it doesn't mean certain packages don't languish because nobody appears to use them, but I'm not personally convinced (at all) that more red tape around ownership would actually change that. Abondoned packages exist everywhere, as do unresponsive maintainers, and I actually feel more likely to bump a random package this way.

<nckx>As you can tell, I am the biased.

<jpoiret>jlicht: now I'm the one spreading disinformation

<jpoiret>i've been running emacs-next for too long, that's probably why

<Guest63>jlicht:: He wrote emacs-next not emacs

<jpoiret>anyone followed the core-updates discussion?

<jpoiret>is the current goal staging or core-updates?

<unmatched-paren>CommGNUism.

<Guest63>jlicht: 28.2 if you want to be specific

<jlicht>Guest63: thanks!

<jlicht>jpoiret: Does emacs-next also report a `emacs-version' of 30.0.50 for you?

<Guest63>Why does "gnu search <package>" take so long? I mean after running it, it is fast but after a system reboot it takes forever

<unmatched-paren>Guest63: i believe there's some kind of package cache

<Guest63>yea, but why is it cleared upon reboot?

<lfam>Perhaps... the page cache

<lfam>In my experience, the page cache is super critical to a lot of Guix operations

<lfam>Just general OS-level caching

<jpoiret>jlicht: it does :)

<nckx>Guest63: AFAIK it's created at build time, not run time, so it's not cleared.

<Guest63>nckx: Okay it worked, though I have the feeling it is not done right. BTRFS uses subvolumes not partitions and I think I did partitions in the installer

<nckx>I also don't see anything too terrible, at least here: https://paste.debian.net/plainh/2e5a1c20

<lfam>Partitions and subvolumes are different things. I'm sure that whatever you did will work fine

<nckx>Guest63: Subvolumes don't obsolete partitions, there are good cases for both, but I don't think the installer offers to create subvolumes like some others do. This is also just to-do, some day, by someone who wants that.

<lfam>Btrfs doesn't require any special set-up

<Guest63>Well for me it is always slow the first time a run it. That means if I reboot the machine it takes a loooong time the first search of the day

<lfam>Guest63: Yes, it's likely the OS needed to page in the relevant data.

<nckx>Maybe I need to do more than drop_caches, or maybe my ooold SSD is zippy compared to yours?

<lfam>Guix stores its data on "disk" is a manner that is hyper-fragmented compared to traditional operating systems, so some relative slowness is normal after boot

<Guest63>I have an HDD, SSD is a luxury I do not own currently

<lfam>Yup

<lfam>Figures!

<lfam>The fragmentation is a killer on HDD

<lfam>Make sure to get lots of RAM to compensate

<nckx>Yeah, Guix is not HDD-friendly in places. :-/

<nckx>I sympathise, I used a HDD for years, but eventually switched and was happy.

<jpoiret>nor RAM friendly :)

<Guest63>I have 16GB 1600Mhz, not really fast either

<lfam>Also, consider shopping for SSDs again, they are super-cheap these days

<nckx>☝

<puddinghead>yeah, if i ever install guix as an os ill prob just have to do so in my main computer

<lfam>I mean, I'm in the US, so lots of things seem cheap to me

<nckx>This is what I was going to say: SSD was a luxury for me when I bought one, but it was a good investment nonetheless.

<lfam>But, 1TB of SSD is about $60

<lfam>And, if you do any kind of "work" with your computer, it pays for itself in time saved

<jpoiret>😳 that's way cheaper than what i envisioned for that space

<Guest63>I do not even have a m.2 slot, but plan to use Guix System and after some time I buy an SSD. (so I can better compare the speed benefits I get from the SSD)

<lfam>2.5" SATA SSD is a good choice

<lfam>Yeah, hardware is really cheap compared to time these days~

<lfam>!

<Guest63>Sure I am going to buy one but wanted to try it Gux first since I kinda want to test the drive speed differences

<Guest63>in Guix*

<lfam>Okay. I can promise you that the results will be astounding ;)

<Guest63>You know because Guix gives me a better constant

<Guest63>nah

<Guest63>m.2 is the one that will change everything

<lfam>No, any solid state storage (even SATA) will be a game changer for random reads

<Guest63>epsecielly now with pcie5

<puddinghead>yeah

<Guest63>isnt it just x6 speed?

<lfam>Don't let the perfect be the enemy of the good

<Guest63>lfam: true

<nckx>‘Just’.

<nckx>ACTION pets their X230 with half-speed mSATA SSD.

<Guest63>one thing about having old slow hardware is, you can easily see which software is optimized or not

<Guest63>kinda like a qa you know

<lfam>Many of here have the knowledge that Guix is generally I/O bound while using spinning disks

<lfam>After that, then it's underlying performance issues in Guile

<lfam>You'll be impressed by the hardware when you make the switch, I am sure

<Guest63>got a different question: Once a year we have a power outage. Will it break my system or deals btrfs fine with it like ext4?

<lfam>I haven't had trouble after years with btrfs, and I sometimes pull the power on my computers

<jpoiret>it should be ok as long as you're not using the buggy raid mode

<Guest63>I can write down your names and tell you my experience in 6+ months if you want

<GNUtoo>hmmm it was the distro wget package that was broken, /me fixed by using curl instead

<Guest63>k nice, good to know thanks

<lfam>The thing is that the storage device (HDD or SSD) has a capacitor to provide enough power for graceful shutdown

<GNUtoo>Guest63: it also depends on the underlying storage

<nckx>GNUtoo: Interesting. The same distro's curl package?

<GNUtoo>Guest63: for instance microSD are known not to be resistant to power outage if they write data

<nckx>jpoiret: The buggy raid modes will happily eat your data either way. Power outages will only get in their way!

<jpoiret>I've been using BTRFS for ~5 years now with no issues, even did an inplace arch -> guix upgrade using subvolumes

<GNUtoo>nckx: yes, Parabola armv7h (based on Arch Linux ARM)

<jpoiret>nckx

<nckx>jpoiret

<nckx>GNUtoo: I'll try to remember that if anyone ever reports ‘weird’ bugs, thanks.

<jpoiret>nckx: let the btrfs ants cook

<GNUtoo>nckx: for some issues I've been having several issues with 32bit wget: files limited to 2GiB on i686, it got fixed at some point, and now that

<lfam>Wow, I'm suprised wget had that limitation in recent times!

<GNUtoo>It's probably some packaging issues

<lfam>Oh, yes, perhaps

<nckx>Part of me's tempted to add a curl fall-back to guix-install.sh, another part (which will probably win) dislikes the complexity.

<lfam>"It's just a little shell script"

<nckx>Actually they are about equal but the lazy part of me is forming a power bloc.

<GNUtoo>Most of it is easy to change

<GNUtoo>for wget -P, we just need a wrapper

<nckx>‘Just’.

<GNUtoo>What is more problematic is REQUIRE

<GNUtoo>Like how do we require wget or curl?

<nckx>Yeah, it's easy, but lfam said it well, this Script is right on the cusp of becoming a Programme and I don't want to be the one to push it over.

<lfam>"Some parts of the code base are hard to understand"

<Guest63>I have an 1TB HDD. What should I give / and /home?

<lfam>I would give 50 GB to / and the rest to /home

<lfam>Guix wants a lot more for the root than traditional distros

<jpoiret>50GB for the store?

<GNUtoo>Guest63: HDD should probably be fine, another thing to watch out is write barriers, it is probably enabled with most common configs,

<jpoiret>with a 1TB HDD i'd even go for 100GB

<lfam>Yeah, even 100GB!

<nckx>lfam: I'd be ENOSPACE with 50.

<jpoiret>depending on what one does with Guix, but you said you were planning on maintaining some packages

<lfam>The consensus is "more than 50"

<jpoiret>your store will grow quite fast

<GNUtoo>basically it ensure that if you have several stacks (partitions, raid, lvm, crypto, filesystem) it writes through the change

<lfam>Yeah, doing Guix development eats up space

<lfam>And you won't want to collect garbage often

<nckx>And I don't even use GNOME or whatever.

<GNUtoo>nckx: anyway for now Guix only supports GNU systems hosts, so shell scripts are probably not that bad

<GNUtoo>like we have less portability concerns

<Guest63>nckx: Do not use GNOME either, going to be EXWM

<Guest63>Okay, so I will go with 100GB; writing it down

<GNUtoo>And the program chosen seem to not change often or to keep backward compatibilty somehow

<lfam>Does our installer offer LVM configuration? That's nice to have with respect to partition sizes

<nckx>GNUtoo: Hmm, I thought someone had made it POSIX-compatible a year or two ago, at least as far as ‘core’ utils went (so you'd need to install wget/gpg/…, but not a GNU-compatible shell/coreutils)? Did that never get merged?

<nckx>Was it a fever dream of mine?

<Guest63>lfam: Not that I am aware of. It does not offer many features.

<GNUtoo>It could also be me seeing portability problems where there are none (because I read scary stuff in autotools manuals...)

<nckx>GNUtoo: There is no ‘POSIX’ HTTP tool, right?

<GNUtoo>Though autotools don't necessarily assume bash and so on

<nckx>> echo GET / | nc …

<nckx>GNUtoo: I don't even think they assume POSIX.

<GNUtoo>I'm unsure but maybe all we need is to make sure we depend on a specific tool like *GNU* wget (and not any wget) and make sure they implement backward compatibility

<GNUtoo>And maybe also use curl just in case it fails

<nckx>Unless you're talking about later emulations like Busybox, GNU wget *is* wget, it's not like ‘GNU ls’ which BSD people grump about.

<GNUtoo>ok

<GNUtoo>there is a shell script that implements wget with curl, but it doesn't implement -P for instance

<nckx>(But maybe you are talking about Busybox, and it would be worth checking!)

<GNUtoo>busybox has less options in general

<nckx>Right. But that script is explicitly (and maybe poorly) emulating GNU wget.

<nckx>Do you have a link to it?

<GNUtoo>I found it in LineageOS

<Guest63>I installed Guix System through the 1.4.0 installer and added the spice service. Now upon running reconfigure it says channel guix is not a descedant of <hash>. Why is that?

<GNUtoo>but the most problematic one is busybox: options are configurable

<Guest63>Note: Did not run Guix pull yet

<GNUtoo>but most distros that have space probably don't use busybox

<GNUtoo>at least not as default for wget

<nckx>‘Remove fake wget | Toybox supports it now, and there is no real need for this tool.’

<GNUtoo>some have it just for the initramfs but in that case you only have 'busybox' installed, not /usr/bin/<some tool> that is linked to busybox

<GNUtoo>ok

<nckx>Just pointing it out, not making a point.

<lechner>nice play on words

<nckx>Guest63: Guix pull yet 😉

<GNUtoo>It's a good point, because if we manage to make Replicant 11 work, I'd like to ship what is needed to make guix-install.sh work and that script too

<GNUtoo>So I'd need 'wget' -P somehow or to have code for curl

<nckx>That would be very cool of you :)

<Guest63>nckx: So I need to upgrade my system first? Why can't I just install a older version? (updating takes ages)

<GNUtoo>It provides many development tools so it would be handy to have it anyway

<nckx>‘guix pull’ does not upgrade your system, only Guix itself and the package versions that it can install.

<GNUtoo> https://redmine.replicant.us/issues/2274

<rice-crispies>"Issue #2274: Enable to install Guix on Replicant 11 - Replicant" https://redmine.replicant.us/issues/2274

<nckx>Guest63: You can, with --allow-downgrades I think.

<nckx>I was just giving the better option, modulo computation time.

<GNUtoo>Right now the blocker is 'gpg', it's ported to Android but it requires autotools

<Guest63>Okay got it. Just weird I get an error msg like this since it kinda indiciates a tempered with time but I did not

<nckx>GNUtoo: Ah, the only truly prohibitive thing to reimplement in (ba)sh :)

<GNUtoo>So I'm not sure how to build it or if there is a way around with some f-droid application that use autotools

<GNUtoo>ah that's easy: we just ship bash

<Guest63>tampered*

<nckx>Guest63: Yes, you are right, this should be fixed, it is at best a cosmetic bug.

<GNUtoo>It was used in old LineageOS versions so we just integrated it

<Guest63>Exactly, that was my point. Just wanted to make sure it is on a list

<nckx>I'm not sure it is TBH.

<nckx>ACTION AFK, but for a real while this time.

<Guest63>(can't get a second impression on people if they install Guix)

<GNUtoo>We'd also need to create some accounts, and so on to not have to do what julien lepellier did, but that's probably doable relatively easily too

<Guest63>GNUtoo: What are you trying to do? Sounds like Guix on smartphone

<roptat>GNUtoo, it's lepiller :p (no i)

<GNUtoo>thanks

<roptat>hi :)

<GNUtoo>Guest63: it's not top priority, the top-priority is to get somehting usable daily with a more recent Android version, but we'd also like to be able to install Guix on top of Replicant

<GNUtoo>Guest63: like you'd install Guix on a foreign GNU/Linux distro

<Guest63>GNUtoo: Ah okay, so basically Android but with Guix as a package manger to install Linux packages?

<GNUtoo>Guest63: there is already unofficial installation instructions by Julien Lepiller here: https://lepiller.eu/en/guix-on-android.html

<rice-crispies>"Guix on Android! â Julien Lepiller" https://lepiller.eu/en/guix-on-android.html

<Guest63>So I could use htop for examlpe?

<GNUtoo>Guest63: yes

<roptat>that's possible, but you have to tweak a few things

<roptat>like, guix uses glibc, and android uses bionic libc, they're not fully compatible

<GNUtoo>indeed

<GNUtoo>It doesn't seem a big issue since Guix provides glibc

<GNUtoo>The kenrel headers just have to match somehow

<roptat>and I still haven't managed to make this setup survive a reboot

<GNUtoo>Though it'd be limited to command line tools only

<GNUtoo>But for having development tools that could work

<GNUtoo>ah ok, in our case it could probably survive reboot since re don't have initramfs anymore in Replicant 11

<GNUtoo>guix packs worked fine at least

<GNUtoo>ACTION tried usbip in this way

<Guest63>Why do different library versions for C exist anyways? Since shouldn't be a "standard" the same on everything?

<jpoiret>because different libcs have different implementations

<GNUtoo>Guest63: some have different goals

<Guest63>but isn't it a standard?

<Guest63>or more like standard and additional stuff?

<GNUtoo>Guest63: part of it is also because it would take time to unify them, for instance glibc support 2 kernels (linux and HURD) but it doesn't support FreeBSD for instance (debian had patches but they weren't upstreamed)

<jpoiret>the standard is just for the user-facing API, but how it's implemented behind the scenes can change

<GNUtoo>Guest63: and AFAIK nobody upstreamed these changes

<jpoiret>ie musl is wayyy leaner than glibc

<jpoiret>and also because glibc is under a copyleft license and Google didn't want any of that :)

<Guest63>jpoiret: Ah got it. That makes sense to me

<GNUtoo>yes but muls doesn't have compatbility code

<jpoiret>right, that's the tradeoff

<GNUtoo>So you need to recompile everything with (big?) musl changes

<roptat>the main issue I had with glibc on android were users... no /etc/passwd

<GNUtoo>Some libc (like klibc) or uclibc (if configured properly) can be way smaller, they are often used in initramfs because of that

<GNUtoo>Some are really specific like Coreboot has a kind of libc (called libpayload)

<GNUtoo>And the issue with all that is that it looks standard for user-facing API but there are differences in the user-facing API in practice

<GNUtoo>The most well tested is glibc, so if you use something else some programs won't compile, so either you fix the programs or you add other systems (like FreeBSD) in glibc for instance

<GNUtoo>Since Alpine (and derivatives) uses musl, at least all programs in Alpine can compile with musl but I'm not sure if it requires patches or if all is upstreamed

<GNUtoo>The same applies to all distros using libc different from glibc (like FreeBSD libc, OpenBSD libc, etc)

<GNUtoo>roptat: for /etc/passwd we can simply patch Android to add users, though you need to recompile to add users like that because they are hardcoded...

<GNUtoo>Guest63: And note that C and libcs are also used in bare metal (no OS like with avr-libc) or even in tiny OS that work fine with less than 2MB of ram like Nuttx

<GNUtoo>There glibc will already be way too big, and it might also need to support the architectures of the hardware too

<GNUtoo>Guest63: also many bootloaders or even kenrel implement some libc or subset of it internally

<GNUtoo>Or at least some of the functions usually exported by the libc

<roptat>oh fun, my computer crashed

<roptat>"general protection fault, probably for non-canonical address 0x2000000000000018: 0000 [#1] PREEMPT SMP PTI" that can't be good, right?

<lechner>nice

<GNUtoo>hmmm, what the traceback says?

<lechner>what led up to the crash, please?

<jpoiret>a stray cosmic ray just hit your ram

<GNUtoo>If the crash is strange it could also be the RAM or dust between the RAM DIMM and the mainboard

<roptat>could be dust

<roptat>I'll clean it

<GNUtoo>ACTION has strange crashes related to audio, and I probably need to cleanup my computer

<roptat>I think it was running aapt2

<roptat>(for building android stuff)

<GNUtoo>dmesg has the traceback usually

<roptat>there's a call trace, looks like it's in the kernel, maybe?

<GNUtoo>Ah if it crashed maybe you can't run dmesg anymore

<acrow>Did I miss a package for gix? I don't see anything on issues....

<roptat>mmap_region+0x318/0xa20

<GNUtoo>So it could be either in /var/log somewhere or if you use uefi in some sysfs somewhere through pstore

<roptat>GNUtoo, I had to reboot, the computer freezed

<roptat>froze*

<roptat>acrow, I have it in my channel, but that one is not even from the channel :/

<roptat>GNUtoo, don't worry, I'll just say it was a cosmic ray and I'll clean the computer (it really needs it I think). Hope it doesn't happen again

<GNUtoo>it should be in /sys/fs/pstore/console-pstore-* according to the kernel documentation

<GNUtoo>But that's assuming you want to bugreport somehow

<roptat>there's nothing in that directory

<GNUtoo>ok, I'm unsure if it has requirements or not

<GNUtoo>ACTION still needs to learn about UEFI

<GNUtoo>ACTION typically uses either a 100%free coreboot+{grub,SeaBIOS} or u-boot

<Guest63>how does Guix detect that a substitute is somehow slow?

<GNUtoo>About that I also need to understand if FSDG distributions have a way to support computers with secure boot that can't be disabled and/or if these computers are common or not nowadays

<Guest63>since the packages are like 10MB are something which doesn't take long even on slow network

<acrow>roptat: :) "it is not from the channel"? gix didn't cause the crash, right?

<roptat>I don't think so

<jpoiret>Guest63: it waits for 5 seconds :)

<roptat>Guest63, I think "slow" means more than 5 seconds without receiving anything

<Guest63>Ah they mean response not speed

<Guest63>thanks

<roptat>maybe the text can be improved

<Guest63>Those substitutes can be run on LAN as well, so could I make a big cache on a Server if I have enough space so I don't need to hit ci.guix?

<roptat>you could

<roptat>I'm not sure if we have instructions to do that

<Guest63>So my idea is that I talk to my server and fetch data from that but if it requires something it does not have it goes to upstream and gets it (ci.guix)

<roptat>you'd run "guix publish" on that machine and use it as your default substitute server

<GNUtoo>I'm super interested in it too, like having mirrors would be great for faster updates and offline usage too

<roptat>I think there's a Chinese mirror, you'd have to figure out how they set it up

<GNUtoo>(obviously without having to recompile everything yourself somehow)

<GNUtoo>wow

<lfam>You can do it with an Nginx mirror

<roptat>oh, all that for a NullPointerException :/

<GNUtoo>Is it just a proxy, or are they downloading the full content of the build servers?

<lfam>Just a proxy

<GNUtoo>ah ok

<lfam>Oh, the Chinese run a full mirror

<lfam>But you can make a simple proxy with Nginx easily

<Guest63>proxy is probably enough for LAN cache?

<GNUtoo>ah nice, I'm more interested in the full-mirror thing

<lfam> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf

<rice-crispies>"mirror.conf\nginx\hydra - guix/maintenance.git - Articles, talks, and documents for Guix maintainers" https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf

<GNUtoo>This way you have the data locally *fast* and it also works offline

<lfam>It's nice except for the part where you have to download everything ;)

<Guest63>ah I'm fine with that. Fun little project

<GNUtoo>For Parabola it's only about 200GiB

<GNUtoo>245 GiB right now

<GNUtoo>And that saves me *a lot* of time as updates are way way faster than before (I've a slow connection)

<GNUtoo>And I can rsync it to my laptop when I travell for instance

<lfam>I don't see how it's practical to download all the substitutes because of slow bandwidth

<lfam>A bit of a chicken and egg problemm

<GNUtoo>The question is more how big they are

<GNUtoo>For Parabola it really saves me a lot of time, it rsync every 15min, so it doesn't require a big bandwith

<lfam>Tbh, I don't think the project should approve rsync access for a personal use case

<lfam>The Nginx mirror is a good halfway solution

<GNUtoo>it's read-only rsync obviously

<lfam>Nevertheless

<GNUtoo>The issue with Nginx is that you need 2 computers to need the exact same binary or source to be useful

<lfam>With the Nginx mirror, you download everything that you need, only once

<GNUtoo>ok

<lfam>If you rsync everything, you download *everything* for every architecture

<GNUtoo>yes, exactly

<lfam>Well, it's not up to me at all

<GNUtoo>How big is that?

<lfam>But, we made the mirror for China, which has >1 billion people. It's a bit different

<GNUtoo>Is it more like 200 GiB or more like 1TB?

<lfam>It's definitely counted in TB

<GNUtoo>ahh ok, that's why

<GNUtoo>And I guess a lot more packages are built all the time...

<lfam>Yeah, constantly, for many branches

<Guest63>Installing Guix on a Smartphone is only not working out of the box because of drivers. Do I understand that correctly? (obviously UX would be trash anyways because no good GUI)

<Guest63>Any Linux to be honest*

<GNUtoo>ACTION really wonders if there is a smart way to fix that but I'm out of ideas

<lfam> https://guix.org.cn/wiki/mirror/

<GNUtoo>Guest63: you mean on top of an Android distribution?

<GNUtoo>Guest63: or as host OS?

<GNUtoo>like guix system on Pinephone

<GNUtoo>thanks for the link

<Guest63>lfam: can't even read it, apparently my font don't support chinese. How can I fix that thing again...

<Guest63>GNUtoo: As a complete OS. You I have a dream of that in the future my Smartphone that runs Guix easily shares files with my Guix PC.

<lfam>Hm, not sure. The font looks a bit rough for me so it might be GNU Unifont

<GNUtoo>Guest63: The easiest for that would be the Pinephone, and there are drivers in that case

<apteryx>nckx: hm, testing ICU in isolation seems to yield the correct result, even without my patch

<Guest63>Though do we have GUIs on Linux for Smartphone devices?

<apteryx>it ends up calling 'tzname', from glibc

<GNUtoo>Guest63: we do, there are still rough edge as not all application work fine on smartphones (no hardware keyboard, ultra high resolution on a tiny screen, no mouse/touchpad but fat fingers)

<GNUtoo>Though on the Pinephone you can add a keyboard and it also improves a lot the battery life

<Guest63>not that bad honestly

<Guest63>going to follow that

<Guest63>Though sadly I still need some Android apps to run. Can I run them in a container or something or isn't that supported yet?

<GNUtoo>It's complicated:

<GNUtoo>(1) not all apps work in container, for instance "silence" won't be able to receive SMS in waydroid

<apteryx>ah, and glibc uses TZDIR (see: man 3 tzname), so it should work fine for the ICU part

<GNUtoo>(2) Waydroid requires a distribution to run and so far we didn't find any FSDG compliant one

<GNUtoo>reference: https://issues.guix.gnu.org/51737

<rice-crispies>"Add Waydroid" https://issues.guix.gnu.org/51737

<jonsger>Guest63: yeah, one is called phosh. works nicely on my Librem 5 :) (although not yet with Guix...)

<GNUtoo>Also using something like waydroid eats more RAM obviously

<Guest63>development progress of my dream setup isn't even that bad as I thought (at least on the SW part)

<Guest63>but I guess without HW it is still 0 progression

<lfam>ACTION remorsefully takes another look at <https://issues.guix.gnu.org/53289>

<rice-crispies>"Removing QtWebKit" https://issues.guix.gnu.org/53289

<lfam>Not much joy for this kind of maintenance work

<GNUtoo>btw, if some people want to review 2 tiny u-boot packages that can even be tested without the hardware?

<lfam>Sure, what kind of review do they need?

<GNUtoo> https://issues.guix.gnu.org/60289

<rice-crispies>"[PATCH v1] gnu: Add u-boot-qemu-arm" https://issues.guix.gnu.org/60289

<GNUtoo>Nobody looked at them so far

<GNUtoo>They can be tested with qemu-system-{arm,aarch64} -machine virt -nographic path/to/u-boot.bin

<GNUtoo>And here I just need 2 packages because users are expected to run it like that: qemu-system-{arm,aarch64} -machine virt -nographic path/to/u-boot.bin -m <some RAM amount like 2047M> -hda <path/to/guix.img>

<GNUtoo>(there is no need to integrate them in an image)

<nckx>lfam: I would not bother with all these individual blockers if I were you. And they seem to be a significant source of the busywork.

<Guest63>If I do not have Guix System but Guix and install fonts, will Firefox use them? I installed font-gnu-unifont but https://guix.org.cn/wiki/mirror/ still displays boxes

<nckx>But maybe they help you keep track of things I guess.

<GNUtoo>btw, with channels if there are known FSDG compliant ones, I could add them to the libreplanet wiki

<quidnunc>How do I implement the my-glibc-locales instructions on this page? https://guix.gnu.org/manual/en/html_node/Application-Setup.html

<rice-crispies>"Application Setup (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/Application-Setup.html

<GNUtoo>so if one day there is a qtwebkit channel that is FSDG compliant (but has known security bugs) I'd be interested in knowing about it

<quidnunc>I tried saving it to a file and running "guix package --install-from-file=foo.scm"

<lfam>nckx: At least they help me keep track. With the current outstanding patches, there is only one remaining direct dependent. Unfortunately it has a few dozen transitive dependents

<quidnunc>But I get the error "guix package: error: cannot install non-package object: #<unspecified>"

<lfam>GNUtoo: Do the patches work for you? Like, have you tested them in your own workflow? If so, I'm inclined to just go ahead and push

<quidnunc>I searched and found that that error is a result of not having a command to build the package at the end of the file but it didn't specify what exactly needs to be included

<lfam>GNUtoo: I would *love* it if someone had a channel for qtwebkit. Then I could avoid all this tedious effort at gathering consensus and avoiding breakage and just rip it all out

<nckx>lfam: Which is?

<GNUtoo>lfam: yes I've tested it when I've submited the patch

<lfam>python-pyqt

<lfam>nckx ^

<nckx>Thanks.

<lfam>Okay, thanks GNUtoo

<GNUtoo>As for the usage in a workflow, I've not tested yet, but it should work anyway

<lfam>That's good enough for me GNUtoo

<lfam>It's not like you are pushing changes to glibc or something

<GNUtoo>ok, thanks a lot

<nckx>lfam: You already have consensus on the big picture, I don't see the need to seek it again for each subtask.

<GNUtoo>ACTION waited for the patch to be merged to start using it for real to try to debug stuff with armhf

<quidnunc>Never mind I got it: "(my-package)" doesn't work but "my-package" does

<nckx>lfam: IMO, but my O's pretty opinionated.

<lfam>nckx: I feel that way, but find it hard to act on that feeling

<lfam>For example, I use the package qgrx that has a transitive dependency on qtwebkit. I'd be annoyed if it got broken for some obscure reason. So I don't want to cause annoyance. Perfectionist, I suppose

<lfam>gqrx

<GNUtoo>ah yes I see

<Guest63>nckx: https://paste.debian.net/1270795/ that is my setup (from the installer basically) and what btrfs fs show prints. Though I couldn't set the first partition to Linux Filesystem as you told. I had to choose between ext4, btrfs and so on. Now I need to make / and /home to an actual subvolume to make use of btrfs features like snapshots for

<Guest63>example since I think it is currently not correct configured.

<rice-crispies>"debian Pastezone" https://paste.debian.net/1270795

<GNUtoo>Could we do like Parabola does: remove support for qtwebkit with --configure-flags ?

<nckx>Guest63: What kind of subvolume/snapshot scheme are you thinking of?

<GNUtoo>Though Parabola does it for qtwebengine usually but a similar thing may work for qtwebkit too

<lfam>Yeah, it could be done, in cases where the package supports it

<lfam>Mainly I want people to pick up the work for packages they care about

<Guest63>definitely /home since easy backup of data though I am not experienced enough to be sure about /.

<Guest63>nckx:

<nckx>Guest63: Speaking hypothetically, were I to trust and use btrfs, I'd keep things very simple and just make /home (or /home/me) a subvolume, no mounting subvol= funny business.

<lfam>The reality is that there is at least one "middle layer" of packages that nobody really cares about

<lfam>We only touch them because our applications require them

<GNUtoo>Guest63: in my case I wanted to share the space between several rootfs, so I used subvolume to have multiple rootfs in the same filesystem

<nckx>Doing so would require 0 changes to the system configuration, just a (very short) dance with /home. I guess I'd boot from a live image for that but you could probably avoid even that.

<Guest63>Don't I need subvolumes to make snapshots work? Like going back and so on?

<nckx>At the risk of being a relativist: depends on what you want, and how you want to go back, and to what.

<GNUtoo>Snapshot work without subvolumes, but I'm unsure if you can make a snapshot of only a folder though

<nckx>GNUtoo: Snapshots are always of a subvolume.

<nckx>/ is a subvolume.

<GNUtoo>ok, so that's why subvolume are important for snapshots

<Guest63>Well basicaly, I just need to backup my /home/cm folder since there is all my data with value but / is obsolete since I can generate that with my /etc/config.scm. Is that correct?

<GNUtoo>It made sense to have it implemented in this way but I wasn't sure if it was actually done in this way

<lfam>Pushed, GNUtoo

<GNUtoo>Thanks

<nckx>If you want snapshots of something other than /, you need to create another subvolume at that level, but this subvolume can be ‘in place’ (/home/foo) and look like any other directory, or it can be in some self-imposed namespace (/@home is a popular one) that you then mount at /home.

<GNUtoo>Thanks a lot!!!!

<Guest63>So my idea is that I make snapshots of /home and send it to another machine for backups

<lfam>I was inspired by your talk GNUtoo. I thought, what small thing can I do to help?

<lfam>Hopefully it helps

<nckx>Guest63: This is just my personal opinion, but I'd keep things simple and make /home an ‘in-place’ subvolume. mv /home /home.bak, ‘btrfs sub cre /home’ IIRC., then move everything from /home.bak to /home.

<nckx>Doing so from a live system (like the Guix System installer) makes it so you don't have to think about in-use files but it's optional.

<nckx>ACTION away.

<GNUtoo>Thanks, the main issue is probably that I work on too much stuff at the same time. Some of the long standing issues are very Replicant related though, like making Replicant 6.0 build with an FSDG compliant distribution, and they might not be very fun to do.

<nckx>(Someone else could explain the more complex but flexible ‘@’ convention if they like. o/ )

<Guest63>can I break stuff by playing around?

<GNUtoo>lfam: there is also a lot of code cleanup to do and here it's less Replicant specific but it might not be very fun either.

<jackhill>lfam: re: psi → psi-plus sure, I can write one, but not right now :) Honestly, I was pleased to find psi-plus not directly depending on qtwebkit too

<GNUtoo>Some is guix specific though

<lfam>No worries, I'll do it jackhill

<Guest63>like I mean if I change stuff in btrfs via config.cm can I lose data by doing stupid stuff?

<jackhill>lfam: ok, thanks!

<singpolyma>jackhill: why are we talking about psi?

<lfam>The cleanup work is always tough to get through. Finding a way to incentivize it is important for the success of any big project

<lfam>Guest63: I can't think of the exact mechanism by which you could lose stuff, but I recommend not removing and creating your filesystems wantonly

<GNUtoo>ACTION has started cleaning up the guix.scm for instance: https://git.replicant.us/contrib/GNUtoo/replicant/hardware_replicant_libsamsung-ipc/log/?h=for-main

<rice-crispies>"replicant/hardware_replicant_libsamsung-ipc - Patches not merged yet, used for building and testing them" https://git.replicant.us/contrib/GNUtoo/replicant/hardware_replicant_libsamsung-ipc/log/?h=for-main

<GNUtoo>But I've still some issues with static builds

<lfam>singpolyma: I want to remove psi from Guix because it depends on QtWebKit, which is going to be removed as well. <https://issues.guix.gnu.org/issue/53289>

<rice-crispies>"Removing QtWebKit" https://issues.guix.gnu.org/issue/53289

<singpolyma>Oh, sad

<GNUtoo>I'm unsure how static builds work though, like how are you supposed to add support for that. If I add -all-static to <progname>_LDFLAGS it somehow works, but I'm a bit lost between the toolchain, autotools and distros like Guix: how a user (guix) is supposed to use that and how it's supposed to be added in autotools

<lfam>singpolyma: Do you know if psi-plus is a worthy replacement?

<GNUtoo>And I didn't even find a man (ld, ld.bfd, ld.gold mentioning the -all-static flag)

<GNUtoo>gcc man/help doesn't have it either

<singpolyma>lfam: I don't know if it misses the dependcy, but otherwise yes it is

<GNUtoo>And the idea behind static builds is to just be able to cross build a binary and copy it on a phone running GNU/Linux or Android and just testing it there

<Guest63>If someone installs Guix System with GNOME we maybe should deliver a decent background as well and not just a blue screen.

<GNUtoo>(Qtwebkit) in Parabola if I recall well, most of the packages that required Qtwebview is for tiny stuff like printing a help, so maybe it can be disabled quite easily for most packages (though IM applications tend to be harder because they sometime use it to render stuff)

<lfam>Hm, unfortunatley I don't know much about that either GNUtoo. I hope someone else is around to help

<GNUtoo>ok, thanks

<lfam>I was talking about static builds

<GNUtoo>Yes, I understood

<lfam>Regarding qtwebkit, the rendering of untrusted content is where I see the risks of qtwebkit at this point

<GNUtoo>There are also cleanups to do in the guix.scm for libsamsung-ril but that is less important

<GNUtoo>yes, and there is also a general risk if it's used badly, like if you do previews of links for instance

<lfam>It would definitely be easier if qtwebkit could get back on the horse and issue updates, but I don't think it's going to happen at this point

<GNUtoo>like it leasks stuff from your conversation

<lfam>Yeah, or escapes a rendering sandbox and does something on your computer

<lfam>It's funny, just updating a package is the easiest thing. Removing it is a huge pain in the ass

<GNUtoo>It depends...

<lfam>Well, yeah, I am exagerrating :)

<lfam>The hardest thing is always the annoying think you happen to be doing right now ;)

<GNUtoo>From the distro perspective yes, from the other side, it might depends...

<lfam>s/think/thing

<GNUtoo>like if you need to port some software to gtk3 and python3 for instance...

<lfam>Yeah, oof

<lfam>More likely, the python 2 project dies out and a totally new project satisfies its use case

<GNUtoo>or just porting Replicant to more recent Android which require a more recent kernel and to adapt all hardware abstraction libraries...

<lfam>Android moves so fast

<GNUtoo>In some cases the conversion between python2 to python3 isn't that easy

<GNUtoo>like with low level buffers or unicode stuff

<GNUtoo>Anyway a solution for all these browser stuff would be to use Gecko instead somehow maybe write some compatibility API between Gecko and webkit

<GNUtoo>There would still be the bootstrap problem with rust on 32bit though

<GNUtoo>But globally it's probably way better

<GNUtoo>Here's an abandonned example: https://mozilla.github.io/geckoview

<GNUtoo>With Webkit at least the API won't change

<GNUtoo>Though as usual it requires people to step in and do the work

<GNUtoo>We had issues in Replicant with webview, so some people looked into it but at the end nothing was done: https://redmine.replicant.us/projects/upstreaming/wiki/Upstream#Embeddable-web-engine https://redmine.replicant.us/projects/replicant/wiki/Presentations#The-Chromium-mess-meets-Android

<rice-crispies>"Upstream - Upstreaming patches - Replicant" https://redmine.replicant.us/projects/upstreaming/wiki/Upstream#Embeddable-web-engine

<rice-crispies>"Presentations - Replicant" https://redmine.replicant.us/projects/replicant/wiki/Presentations#The-Chromium-mess-meets-Android

IRC channel logs

2023-02-14.log