<vagrantc>does anything in guix provide tinfo.a ? in debian it's part of ncurses ... ***lukedashjr is now known as luke-jr
***jonsger1 is now known as jonsger
<kitty1>yknow; while this isn't relevant for me: has anyone gotten guix *system* to work on powerpc yet? <jab>kitty1: I know guix works on power...idk about system... <kitty1>yeah, I know that as well ; just kinda curious if anyone has managed that yet ***alMalsamo is now known as lumberjack123
<UnderSampled>What is the state of KDE for Guix, e.g. as an option in the installer? <cat[m]>UnderSampled: Why do you need kde? <cat[m]>I dont think DEs do anything but keep your workflow unoptimized <UnderSampled>or at least, that's what it felt like when I tried to look into it a couple years ago <cat[m]>UnderSampled: Years can change a lot <cat[m]>Youll see when you install to vm <Ribby>I was able to initiate flatpak, but the instructions are mixed around so it requires a bit of documentation. <Ribby>I found out that launchers could be used as one mouse click gui of terminal cli commands. <Ribby>launcher's properties windows; command parameter string value: "flatpak run org.gnome.Epiphany". <UnderSampled>Took a bit to find the documentation on it; these are the supported ones, currently. KDE is not currently supported <Ribby>Works on either desktop screen or panel2. <UnderSampled>I'm really just looking for the project to get it working, to see the state of it and cheer them on <Ribby>KDE? Isn't that from Parabola's desktop environment? Looks simple, but classy/flashy/classy flashy. <iyzsong-w>and i mostly use kde applications with sway nowadays... <Ribby>I like the gnome classic's application menu. Something about that organization, just something. <Ribby>I see that mkfs is now available in the system server/repository. I will make my dues due to request. Thank you very much. <Ribby>It depends on the design. There's simple and there's complications. I wouldn't know much so I'm just picking at straws. <UnderSampled>I think they do a pretty good job. Certainly not as simple as some of the minimalist tiling window managers, but It's fairly performant, and their suite has fairly good stuff in it, like Krita <Ribby>lots of layer work right there. <Ribby>abstract art? shading? contour? <iyzsong-w>i wrote my university homework in kate/kde3/slax, while most classmate use turbo-c :D <Ribby>I recently fiddled with this komorebi animated wallpaper engine and zsh/oh_my_zsh terminal shell (deals with command prompt themes/configuration and some plugins of some sort). <Ribby>turbo-c seems to be discontinued. <iyzsong-w>i'd like to package kde1/2/3 in guix somedays... <Ox151>hello, are there any recommendations on debugging NetworkManager for wifi cutting out? I do not have this issue with Parabola. ***iyzsong-www is now known as iyzsong-w
<Ribby>If anyone is wondering about Komorebi, I could apply animated gif image, video loop recording , (24/7) live streaming real-time/video file/url, webpage as newspaper frontpage reading, webpage that selects and redirects to image, webpage that time cycles to display random image, webpage as (24/7) live streaming radio file/url, and webpage as host for (24/7) live streaming stop-motion/digital-stills file/url. <Ribby>Webpage can host multiple media player div sections to run simultaneous media file/url, but networking performance will suffer due to data transmission constraints. <lfam>Ox151: What kernel version are you using? `uname -a`? <notzmv>anyone got any general tips on how to migrate to guix from another distro? <lfam>Ox151: You could check those logs I linked to and see if it sounds like your problem <Ox151`>just uninstall the problem kerenl and install the older kernel i want to try and reconfigure the system? <Ox151>I am trying to downgrade my kernel version. I removed the version i do not want and installed the version I want. It shows in the package generations the one removed and the one currently installed. I then did a system reconfigure to try and apply the changes, but it still keeping the kernel version I do not want. Am I missing the command neede to apply kerenl updates/changes? <Ox151>is it not system reconfigure? <Ox151>yeah there defiantly is issues with wifi connections on kernel version 5.16.17. I just went back to my first system generation of kernel 5.15 and it works fine now. ***Guest87 is now known as meso
<abcdw>tschilptschilp23: Glad to hear. You are very welcome!) <jpoiret>Ox151: did you use guix install and guix remove for that? That won't affect your guix system configuration at all <attila_lendvai>damn! i think i know why my server was building stuff for 15+ hours, including packages that were surprising to see being built locally: there was a temporary network glitch, and it has put my `guix system reconfigure` invocation into a dead-end of local rebuilding, without much warnings. i have cancelled it just now, restarted it, and now it's busy downloading and grafting instead. <GNUtoo>Hi, it seems that the guix-install.sh script has some issue <GNUtoo>Then there are again more web issues: "[ FAIL ] Could not obtain list of Guix releases." <GNUtoo>with curl that's not blank though <ahriman>I cannot reproduce that, I wget it and get the list of releases. <GNUtoo>ok, so maybe something is wrong with the wget I use <GNUtoo>so maybe it's an issue with my certificates or somehting like that (the clock is right though) <AleQu[m]><notzmv> "anyone got any general tips on..." <- Did you already try guix as a package mange within your current distro to get the hang of it? <AleQu[m]>* Did you already try guix as a package manger within your current distro to get the hang of it? <ahriman>guix as a package manager? weak. use guix with emacs as your IDE. *GNUtoo will use http instead of https and that should workaround it <GNUtoo>Guix can be used for many things... <ahriman>does guix edit ignore the EDITOR env variable? <GNUtoo>One of my use cases doesn't involve installing packages at all, just building them to do compilation tests with strict cflags and in various situations (guix.scm) <ahriman>nevermind, it does respect $EDITOR, i was just defining it wrong. <DivanSantana>anyone using nix pkg manager on guix system? is it best to use the nix pkg provided within guix? (I think it might be old, but hopefully it works fine) <wehlutyk[m]>I'm making slow progress with configuring Guix System on rock64, starting by cross-compiling a simple image on x86_64 <wehlutyk[m]>then flash this to sd card (and grow the partition created), boot the rock64, and ssh into it <wehlutyk[m]>`guix pull` fails with: `guix pull: error: Git error: the SSL certificate is invalid` <rekado>you may need to set env vars such as GIT_SSL_CAINFO, SSL_CERT_DIR, and/or SSL_CERT_FILE to the correct locations of nss-certs <sneek>rekado, apteryx says: hi! let me know when you have a chance to look at the build farm again (fixing node 129's bootloader, or reinstalling it) <rekado>apteryx: hi, I’m back from holidays now. Can we reinstall this node remotely? <wehlutyk[m]>rekado: thanks! I'll try that again, but pretty sure I tried the combinations of that and it didn't change anything <rekado>apteryx: the problem was with not having access to NFS early on due to an iDRAC limitation? <rekado>wehlutyk[m]: I thought that “guix pull” used its own certs (from lets-encrypt…?) <rekado>FWIW I’m installing Guix System on rockpro64 :) <wehlutyk[m]>rekado: that's maybe it, as wget and git don't seem to have any problem <wehlutyk[m]>a second problem is that, after the first reconfigure, trying to run a new reconfigure fails with `guix system: warning: unrecognized boot parameters at '/var/guix/profiles/system-2-link/parameters'` (full log here -> https://paste.debian.net/1236120/ ) <jpoiret>did you run `guix pull` after installing? <jpoiret>maybe the guix package should have its version bumped to avoid these issues <wehlutyk[m]>jpoiret: yes, at first boot with the image flashed by the "bootstrap" config above <jpoiret>a27e47f sounds like a very old commit iirc <jpoiret>this is the fixed version of the guix package, so you're not using the `guix pull`ed guix but rather the globally installed one that's old <jpoiret>the issue is that the installer images install an older guix than the one on the live image <wehlutyk[m]>ah, which guix gives `/run/current-system/profile/bin/guix` <wehlutyk[m]>even if I build the image with guix system image ... ? <jpoiret>right, that's not the guix pull'ed one (should be /home/user/.config/guix/current/) <jpoiret>well, no, with the guix system image it should be okay <nouun>I'm trying to setup C dev and need libedit, but using 'guix shell libedit' still outputs no such file when compiling. Is there something I'm missing? <jpoiret>oh my bad, you're not using the guix system image to get an install live system, but rather to use the image itself? if that's the case then no you'll run into the same issue <wehlutyk[m]>jpoiret: yes, I'm building the image and flashing to sd <jpoiret>you're building the image with a very recent guix, but the guix installed onto the image will be old (pre-boot parameters change) <wehlutyk[m]>Ok. So should I just `guix install guix` and I'm good? <jpoiret>you'll need a guix pull`ed guix to reconfigure <jpoiret>no, that'll give you the same thing (never do `guix install guix` btw) <ahriman>something bad happens if you do `guix install guix`? <jpoiret>the issue is that the guix package is updated sporadically when important things change, like the guix daemon, or things for the install image <jpoiret>ahriman: no, but it most likely won't do anything for you <jpoiret>there may be some uses for it but i'd say 99% of users will not need it <jpoiret>guix pull on the other hand fetches directly from master, so it's as up to date as it could be <jpoiret>as long as you do not disable authentication <rekado>nouun: can you share the build log? <wehlutyk[m]>jpoiret: okay. So what's the problem with a27e47f then, an outdated le-certs? <jpoiret>wehlutyk[m]: well, I was talking mostly about the reconfigure problem. As for the certs, I don't know but that might be it <jpoiret>although I don't think 2 months old guixes wouldn't be able to update <nouun>rekado: 'src/main.c:5:10: fatal error: editline/history.h: No such file or directory' <wehlutyk[m]>jpoiret: would there be a way to produce an image with the latest guix package? <jpoiret>i'm currently working on that (at a snail's pace though) <jpoiret>nouun: i think you need `guix shell gcc-toolchain libedit` <jpoiret>otherwise the search-paths for gcc won't be set <nouun>jpoiret: I have a manifest file which has both of them. <rekado>nouun: hard to tell anything from that one line. I’m missing context. <nouun>Oh I feel dumb, forgot to pass '-leditline'. <jpoiret>I would've completely missed that as well <jpoiret>oh, nss-certs doesn't cross-compile? i'm not familiar at all with cross-compilation issues, all i've got are x86_64 <apteryx>rekado: sadly we cannot reinstall the node remotely, due to having an express license instead of whatever Dell's paid license is called (the os deployment feature in iDRAC is a paid feature) <apteryx>so it seems we must go through a physical/on-site reinstallation of the node via USB or similar <wehlutyk[m]>I'm very new to cross-compilation, so I have no idea where to start fixing it. It can't be complicated as it's just at the install phase. <jpoiret>oh, that shouldn't be too much of an issue <jpoiret>it seems it's using the old build phase syntax <apteryx>I still don't quite understand how 'grub install /dev/sd{b,c,d}' on that machine managed to screw up /dev/sda's boot <jpoiret>hmm, annoying, I can't test building nss-certs locally because it's in my system profile <jpoiret>how does that work? does it modify the derivation somehow? <jpoiret>i was using --no-substitutes --rounds=2 :p <jpoiret>i'm trying to grep %output in the repo to see where else it appears <apteryx>jpoiret: the previous installation was using grub-bootloader (non-UEFI) version; so /dev/sda should have had its bootloader installed to MBR <apteryx>jpoiret: I'm not sure of the implementation details, but it is akin to ignoring the /gnu/store cache; if you use --keep-failed (-K) you can then also keep the resulting build it if differed from the previous one, useful to find reproducibility issues <apteryx>which you can feed diffoscope like: diffoscope /gnu/store/...-thing{,-check} <jpoiret>apteryx: did you switch from legacy bios to UEFI booting? just throwing out simple ideas :p <jpoiret>wehlutyk[m]: it's pretty annoying how this issue only shows up when cross-compiling, i'm trying to figure out why <apteryx>jpoiret: not at the time of my initial attempt, no! hehe, thanks for the ideas, simply discussing the problem in various ways often helps to better our understanding of it <apteryx>rekado: also, I hope you had a good time while away :-) <jpoiret>uhmmm, so apparently guix/build-system/gnu.scm's gnu-build uses (with-build-variables ...) to set the legacy %output and %outputs, but gnu-cross-build doesn't and manually sets %outputs but not %output, which is why <jpoiret>that means that a lot of packages using the legacy style will just not cross build at all <apteryx>that explains why we see many commits fixing things by using the new style <apteryx>jpoiret: wait, these things are not documented <apteryx>and we don't want to support them in the future either; so I'm guessing the bugs should be fixed by migrating to the new style? <jpoiret>right, but then we should remove %output as well <jpoiret>because here people trying to cross build will be running into issues that most people won't <apteryx>yes, we can do so after we're sure we won't be breaking more packages <civodul>apteryx: i think you'd want (define bv (make-bytevector block-size)) outside of the loop <jpoiret>i'll open a bug report anyways, so that we can discuss it (or maybe guix-devel?) *civodul has yet to benchmark things <apteryx>I was using (define bv (get-bytevector-n input position)) to define it (outside the loop) <apteryx>(as a way to both 1. initialize the bytevector and 2. populate it with its initial value) <civodul>that gives you a bytevector of at most POSITION bytes <civodul>so that's not what you want, i guess <civodul>and it's a weird way to allocate a bytevector :-) <apteryx>that comes from (rnrs bytevectors) ? <wehlutyk[m]>thanks all, I have to go, but looking forward to that %output thread! <rekado>apteryx: the /dev/sd* names are not deterministic. <apteryx>rekado: but grub install runs after the machine has booted; where we can inspect lsblk and friends and ensure that yes, /dev/sd{b,c,d} are indeed what I think they are <rekado>so isn’t it possible that after a reboot we got different disks for /dev/sd{b,c,d} than expected? <rekado>so… to fix 129 I’d have to visit the data centre and plug in a USB drive… <rekado>we could also use this opportunity to revisit PXE boot <rekado>way back I tried to install Guix System over PXE but our image wouldn’t work for various reasons. <rekado>I could drop a new installer image on our PXE server and see if we could boot from there <apteryx>that'd be awesome; but would it need to be supported by iDRAC? I'm not well versed in PXE booting. <nckx>Ox151: Did you figure out how to downgrade your kernel? *civodul is cooperatively scheduling tasks, hence some latency <civodul>some tasks are less cooperative than others! <Ox151>nckx: good timing with the reply :) I did not. I have to go back to my first generation. But i do not know how to `choose` which kerenel I want to have at any given time. <jpoiret>you'd have to modify your config.scm file, `guix install` and friends won't help you with that <nckx>I worried you were 'guix installing' random kernels which does nothing. <nckx>It takes a variable name, which can sometimes be confusing. You can use (specification->package "linux-libre@VERSION") where VERSION is one of those printed by 'guix show linux-libre'. <Ox151>jpoiret: nckx thanks, i will look at adding a modification to my config.scm <rekado>apteryx: no, the machine will boot from PXE when the boot order is adjusted. Now it boots from PXE only when there’s no local system. <nckx>(For neatness, 'guix remove' all linux-libres, they don't do anything but slurp space.) <apteryx>rekado: and we already have a PXE server? <apteryx>do we have some service to setup a a PXE server in Guix? <apteryx>eh, even attempting to read 1 byte from the zstd-input-port with get-bytevector-n! fails with In procedure get-bytevector-n!: Value out of range: 1 <apteryx>ah, I think start is used as the position in the receiving buffer, not as the seek address in the source port <civodul>apteryx: "out of range" means you're trying to read past the end of 'bv', IOW: position + block-size > (bytevector-length bv) <apteryx>I guess I need to eof-object? the return value, not the bv itself <jpoiret>would we be interested in including GRUB patches for LUKS2 support on install, until something makes its way into the next point release? <jpoiret>the patch defaulting the graphical installer to LUKS2 was reverted because grub-install is finnicky, but people using manual installs might still run into the same issue <jpoiret>i've already distributed my own patches to some people who reported it worked ok <civodul>jpoiret: are these patches now upstream, in GRUB? <civodul>also, what are other distros doing? :-) <jpoiret>no, the current situation (to my knowledge) is that there are 4 patchesets sitting on the ML adressing the same issue, but no reviews yet <civodul>so GRUB is just as good as Guix when it comes to patch review :-) <civodul>so i guess distros are shipping one of these? <jpoiret>not sure, i think suse does (since one of the patchsets was sent by an @suse.org), i'm going to sift through the 194 (!!!!) patches to grub2 in suse <jpoiret>arch doesn't either, so I guess nobody does <civodul>i'd say that if LUKS2 support is deployed elsewhere, and if the patches are likely to make it in GRUB eventually, we can add them <civodul>conversely, if it's experimental or in flux, we'd rather wait <vldn>eehm is it possible to declare home manager config inside my config.scm? <jpoiret>the issue is that GRUB is supposed to support LUKS2, but grub-install doesn't (hehe) <rekado>our pyyaml is pretty old (two major versions behind). This leads us to not being able to update snakemake (also two major versions behind). <jpoiret>archwiki currently recommends an AUR package with a dubious patch applied <rekado>I’ll start a new wip-pyyaml branch to update pyyaml and fix all the problems this causes. <apteryx>civodul: GRUB is also worse than Guix when it comes to closing fixed bugs in Debbugs <rekado>I remember a talk at FOSDEM where a GRUB maintainer said they were not happy about distros bundling hundreds of patches without upstreaming them. <civodul>apteryx: ah that's "good news" i guess? ;-) <civodul>but yeah, it seems like a small project with a lot of pressure and little support <jpoiret>it seems pretty horrible to have such a widespread piece of software maintained by so few people <apteryx>how does this work? I guess only the Savannah admins of the project can close issues? <jpoiret>oh noes, logs.guix.gnu.org's search is still very wonky <jpoiret>searching for nss-certs only gives results back in 2021 <rekado>jpoiret: would you like to try to fix it? <rekado>I think the problem was that the indexer operates on a different database than the web server <jpoiret>unfortunately my TODO list is already growing way too fast <jpoiret>and if it's an infra problem i'm not sure i'd be qualified enough for that instead :p <rekado>overflowing TODO lists is why it’s still broken :p <rekado>I’m getting this on “guix pull”: guix pull: error: bind: Permission denied <alethkit>I'm getting errors for an unbound variable when including a home service, despite the module being imported <alethkit>Removing the import just causes the error message to have a traceback at my config file, instead of at ice-9/eval.scm <civodul>rekado: could it be a wrong TMPDIR value? <civodul>so, the Shepherd 0.9.0rc1 is out *and* there's a wip-shepherd-upgrade branch to try it out! <jpoiret>alethkit: would you mind pasting the relevant part? <rekado>civodul: yes! TMPDIR is set. That’s probably it. <leinad>jpoiret: just read your mail "Deprecating legacy build phase style when cross-compiling vs. native" on guix-devel. Would it help if I grep for %output and fix some packages to use the new style? I've got some spare time. <jpoiret>it would be the proper way out, but on my initial investigations it seemed like a lot of work (and a likely world rebuilding change) <leinad>it is a lot of manual work I guess but I think it's a good opportunity for me to contribute some easy patches :-D <user_oreloznog>civodul: thanks for the blog post about 'guix home". redshift and idutils are running right now! <civodul>user_oreloznog: neat, glad it's useful :-) <acrow>I'm about to add (search-input file inputs "/lib/m2/junit/junit/4.12/junit-4.12.jar") to a package definition. <acrow>Is there some reason we don't symlink that file to, say, /share/java/junit.jar? <acrow>The duplication of version specifics also worry me. <alethkit>jpoiret: Of the config, or of the error message? <gnucode>looking at that paste myself, I may have violated the guix conventing of ending the name of record type with "-configuration" <efraim>looks like I need to check guile-fibers on slow architectures and see if I need to skip any tests <efraim>I think I remember one of them taking hours <maximed>efraim: FWIW, they take long on x86_64 as well <efraim>I don't remember it taking too long on my machine, but I got a fast one finally for x86_64 <maximed>Some tests are like ‘do foo N times’, where N is a huge number, e.g. 5000000 <efraim>that's the one I was going to drop <maximed>IIRC it was something like hours, or at least NN minutes on my machine as well? Will run "time guix build --check guile-fibers". <viivien>Hello guix, let me blow the dust that has settled on #53402 <viivien>Is there someone that has python packaging knowledge? <acrow>It is just a detail, but the convention to canonicalize in this way would make it easier for people. <AIM[m]>How do I access the guix package definition in /etc/config.scm in guix install command? <AIM[m]>Like I wanna like have my custom dwm build installed locally with guix install <maximed>AIM[m]: You don't -- /etc/config.scm is conventionally for Guix System stuff, not "guix install" <maximed>I suggest "guix install -f dwm.scm", where "dwm.scm" ends with a package record for the custom dwm <efraim>weechat-3.5 builds on riscv64-linux <maximed>though given that it's a window manager, not sure if that's sufficient <AIM[m]>But can I ask if it installs every package definition in the file? <AIM[m]>maximed: My package is actually inheriting the existing dwm in guix channel <maximed>AIM[m]: No. However, you could try ending the file with a (list this-package that-package ...) <AIM[m]>Idk it's just that I kinda use pywal <AIM[m]>And my dwm uses the colors file from it <acrow>There is probably some reason to not do it, IDK. <AIM[m]>Probably should change dwm to get colors from xresources instead maybe <maximed>efraim: One of the tests took 227.203693116 seconds. Not quite ‘hours’ but still long <efraim>that one took 171.561047523 seconds on my machine <maximed>assert terminates: (run-fibers (lambda () (do-times 100000 (spawn-fiber loop-to-1e4))) #:drain? #t): ok (227.203693116 s) <maximed>assert terminates: (run-fibers (lambda () (do-times 100000 (spawn-fiber loop-to-1e4 #:parallel? #t))) #:drain? #t): ok (253.674336515 s) <efraim>assert terminates: (run-fibers (lambda () (do-times 100000 (spawn-fiber loop-to-1e4))) #:drain? #t): ok (171.561047523 s) <efraim>assert terminates: (run-fibers (lambda () (do-times 100000 (spawn-fiber loop-to-1e4 #:parallel? #t))) #:drain? #t): ok (67.494140191 s) <maximed>efraim: Is that on a x86_64 or on a riscv64? <efraim>looks like the non-parallel version aborted this time on riscv64 <tschilptschilp23>civodul: thanks for the great blog article. I have one question -- does home eventually do some kind of 'backup-work'? I'm asking, because while reading the text I got stressed out a bit, as I was close to 100% sure that I deleted ~.bashrc~ and ~.bash_profile~ in the place where guix-home points to (just having forgotten, why they are at this 'uncommon' place). Quite upset I just checked, and they still (again?) seem to be there! Or am <efraim>1073.3 seconds total for the check phase on x86_64 <tschilptschilp23>sorry, found the 'culprit' (aka myself). history tells me, I indeed planned to delete them, but forgot the dots, fortunately! <acrow>maximed: I see you comment re issues#32947. IDK if this is a bug or not. I didn't think validated URI's are allowed to contain such characters. Such characters need to be encoded in valid URI's, eg ">" -> > "&" -> "&", no? <nckx>That doesn't mean it's valid XML. <maximed>nckx: Indeed. I think the URL needs to be encoded before being put in the ‘... href="’ <nckx>Yeh. ‘XML-encoded’, not URL-encoded 😉 <nckx>(If I'm following; just happened to glance at IRC… pom pom.) <alethkit>jpoiret: I posted the config above, but let me know if you need more information <efraim>civodul: on the wip-shepherd branch, in the fork+exec-command commit, is "(primitive-_exit 127)" a typo? <gnucode>is there a fairly simple (minimal dependancies) wayland terminal packaged in guix? Termite works for me, but it's developers recommend to switch to something else. alacritty won't work for me... it tries to use OpenGL 3 I think, which my hardware does not support. <gnucode> I might try gnome terminal again... <maximed>efraim: FWIW, primitive-exit, primitive-_exit and exit are all existing procedures in Guile, with different semantics <efraim>maximed: I figured primitive-_exit was a typo <maximed>efraim: phase `check' succeeded after 2481.9 seconds <efraim>maximed: I keep on aborting on riscv64 and powerpc <jpoiret>gnucode: i think xfce-terminal works but I'm not 100% sure <jpoiret>maybe kitty, not sure how bloated/opengl-less it can be <efraim>assert terminates: (run-fibers (lambda () (do-times 100000 (spawn-fiber loop-to-1e4))) #:drain? #t): ok (857.826418911 s) <efraim>assert terminates: (run-fibers (lambda () (do-times 100000 (spawn-fiber loop-to-1e4 #:parallel? #t))) #:drain? #t): ok (183.716854129 s) <jpoiret>alethkit: and what's the exact error? <unmatched-paren>gnucode: for a wayland terminal i can wholeheartedly recommend foot(1) <unmatched-paren>it's VERY minimal; it does all its rendering with pixbuf and directly calls into wayland-client (so it actually won't work on x) <gnucode>unmatched-paren I will try that out. thanks! <apteryx>civodul: I'm reconfiguring my system on wip-shepherd-upgrade <acrow>maximed: Very community minded bug report. Still, if the URI's are percent encoded they would be ok. Reading https://www.rfc-editor.org/rfc/rfc3986.html#page-14 the nonreserved characters you identified should be percent-encoded. Entities like &, >, etc... are another layer of the tower of babel. :) I'm sure the apache people will address it and I will be interestied to see what they have to say. Thanks. <jpoiret>i've gotta go, and i'm not very familiar with guix home code, maybe you'll have a bit more luck with bug-guix <apteryx>civodul: your branch seems to have reduced my boot from about 5 to 3 minutes! <civodul>apteryx: woohoo! but... do you literally mean 3 *minutes*? *civodul rebased + pushed wip-shepherd-upgrade with the correct tarball URL *unmatched-paren doesn't actually have any issues with boot time (currently about 3-5 secs...) but wants to see how fast they can get it to go :P <civodul>tschilptschilp23: "guix home reconfigure" backs up files not managed by itself that it would override <ekaitz>hi guix I'm having issues with guix time-machine: error: %guix-register-program: unbound variable <vagrantc>rekado: i finally dug out my rockpro64 to see if i can't help a bit <vagrantc>of course, my guix install on it was over a year old :/ <vagrantc>also, trying to update u-boot in guix ... but the whole openssl/GPL incompatibility issue is getting increasingly difficult to workaround ... <atka>is there a list of guix compatible SBCs somewhere? <civodul>ekaitz: it does; what's the target commit of your time machine? <civodul>the (guix config) module used to have that %guix-register-program variable <ekaitz>i need to recompile the old gcc-4.7 <civodul>if it's before 0.15.0, forget about it <florhizome[m]>civodul: is there such a thing as release notes for the shepherd upgrade? <vagrantc>atka: don't think so ... and "compatible" is of highly variable interpretation <ekaitz>civodul: so if it's older than 0.15.0 the time machine won't work? <vagrantc>sneek: later tell atka some SBCs are very roughly supported in guix ... there's no list that I know of <florhizome[m]>It‘s a bit sad; at least to other GNU distros it could be a valuable program. But where I see it discussed people don’t know how to use it/implement it <vagrantc>wheee .... Authenticating channel 'guix', commits 9edb3f6 to ecb2603 (20,796 new commits)... <ekaitz>civodul: still trying with more recent commits and it's failing: invalid build result (#<derivation /gnu/store/4wpp8bf26aznqgc8gnsrr34ljksdbgq1-compute-guix-derivation.drv => /gnu/store/y7wh41vhvbqc7h4rac56xa016kb8ybkn-compute-guix-derivation 7f9db8db9f50> "") <apteryx>civodul: yes, literally 3 minutes :-) <apteryx>on your branch, why does 'shepherd' need a rebuild cycle to be bumped to latest? <civodul>apteryx: on master "guix refresh -l shepherd" lists 2,411 dependents <civodul>yes, fixed that in the meantime, sorry! <civodul>apteryx: that's because elogind depends on shepherd, apparently <vagrantc>so, to update u-boot, i need some extra flags passed to ncurses to enable libtinfo ... but that's pretty much a world-rebuild ... ok to put a ncurses/tinfo variant package? i don't think u-boot even uses it at runtime, just build time <vagrantc>or rather, u-boot definitely ddoesn't use it at runtime :) <vagrantc>i also saw some haskell package do something weird to get tinfo support out of ncurses <civodul>vagrantc: hey! i guess it's fine to define an ncurses variant for use by u-boot <civodul>eventually we'll make it the default ncurses <vagrantc>although i don't know what to do about openssl/gpl issues :/ <apteryx>in gnu/build/shepherd.scm: primitive-_exit; is this a typo? <civodul>vagrantc: is that still a thing? didn't openssl change licenses? <vagrantc>but otherwise i think i have patches to update u-boot to current (well, 2022.04-rc5, release in a few days) <vagrantc>civodul: openssl-3.0 changed licenses which will be compatible with GPLv3 <civodul>apteryx: nope! there's exit, primitive-exit, and primitive-_exit (like _exit(2)) for when you really want to leave right away <civodul>vagrantc: oh ok; then... perhaps do the same as Debian?... :-) <vagrantc>civodul: decree openssl is a system library and shove the dirt under the rug? <vagrantc>interestingly enough, seems like *new* code is starting to use gnutls in u-boot ... <vagrantc>i guess that's a question for the guix-maintainers ... <vagrantc>the other question is there may not actually be any embedded openssl *code* in guix though a code audit is a difficult game to play, and at some point someone might slip some embedded code in... <apteryx>civodul: how fast is your system booting now compared to before? <rekado>vagrantc: I have patches for a more recent u-boot <vagrantc>i have patches that get it to build, but i haven't had a chance to test any of them ***LispyLights is now known as Aurora_v_komose
***Aurora_v_komose is now known as Aurora_v_kosmose
<civodul>apteryx: i've only tried in a VM so far, but even with the childhurd, i'd say it's a bit less than one minute (after i've entered my root LUKS passphrase) <rekado>took me a while to adjust the patch <civodul>apteryx: i don't expect a significant change, except that now things keep going while the childhurd starts <rekado>I also added patches to boot from PCIe, but that doesn’t quite work :( <rekado>at least my rockpro64 resets right after successfully enumerating PCI devices <apteryx>civodul: yeah! well from 5 to 3 minutes in my case is already pretty signifant (the boot time was almost halved!) <rekado>I see that it discovers the connected SSDs, but it resets right after that <vagrantc>rekado: probably doesn't make a lot of sense to update to u-boot 2022.01 with 2022.04 to be released ~monday <vagrantc>rekado: can also ask on #u-boot and/or #linux-rockchip for help getting PCIe working properly, or if there is other WIP progress on that... <vagrantc>rekado: but yay, you figured out my openssl dillema :) <civodul>apteryx: would be nice if you could share the "Service .* has been started" lines from /var/log/messages, with timings, to have an idea of what's taking time <mhj[m]>Hi Guix, discovered the Singularity service! Anyways, was wondering how to get it work. Whenever I try to run it, it says "Command not found", but I do have Singularity-mount-helper and 2 other Helper commands, but they just show the Singularity service configuration and exit... <sneek>Welcome back mhj[m], you have 1 message! <rekado>mhj[m]: I haven’t used that service myself, but perhaps we can help if you could share some more information. <civodul>the test produces a squashfs image and then tries "singularity exec" & co. <mhj[m]>OK, I think I'm realizing what I did wrong... I think I also need to evaluate it as a package too and not just as a service? <apteryx>civodul: I'll copy the log from the boot until "Service root has been started" <apteryx>civodul: you'll find the file at berlin:/tmp/maxim-boot.log <alethkit>home configs should have no functional difference if they're set up as a module as opposed to a file, right? <vagrantc>rekado: then /boot could be on the microSD and it could load kernel+initrd+dtb from there, and you could configure your rootfs on the sata/nvme/etc. there <apteryx>civodul: I'm a bit confused looking at the boot log time stamps <apteryx>the kernel longs are in seconds, right? (e.g. localhost vmunix: [ 0.492544] corresponds to 0.49s post boot?) <vagrantc>rekado: er, configure your rootfs from initrd... <vagrantc>rekado: that approach has numerous other potential use-cases too <alethkit>Is there a way of getting detailed guile debug info? <apteryx>yet, compare: "Mar 30 15:26:26 localhost vmunix: [ 0.000000]" with "Mar 30 15:26:51 localhost vmunix: [ 0.470115] devtmpfs: initialized"; so 0.47 s in kernel corresponded to 15 s for Shepherd? <alethkit>Guix seems to recognise the exported variable, but not the internal definition in the module <alethkit>Commenting out the relevant export only seems to change the hint message <rekado>vagrantc: sounds like a good idea <rekado>we’re doing that sort of thing on berlin, because /gnu/store is not available when the server boots. <vagrantc>oh, so you have other significant motivations for that :) <rekado>vagrantc: on berlin we just copied the kernel and initrd to local storage and made grub refer to that location. <rekado>It alll just worked itself out somehow; we didn’t need to do anything special to pivot to the new rootfs on boot. <vagrantc>would be nice to support that kind of process out-of-the-box :) <vagrantc>a "simple" implementation could "just" copy all the relevent store items into the same paths, so you wouldn't even have to mangle grub <vagrantc>(maybe you'd have to mangle grub for the filesystem to load from) 
