IRC channel logs

2020-11-11.log

back to list of logs

<mbakke>lfam: it was a tough one
<lfam>Yes, that's true
<lfam>And Rust is generally tough for Guix
<civodul>apteryx: good!
*civodul -> zZz
<nitro_>when reading guix-install.sh, i see [ "${TERM+set}" = 'set' ] . just curious if anyone knew why that would be used over [ -n "${TERM}" ]
<lfam>Interesting question. I'd guess that either 1) that is the construct the author was more comfortable with or 2) we aim to support some weird environment without a POSIX implementation of [
<lfam> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html#tag_20_128
<lfam>I notice this construct used in a few other locations
<mroh>I'll take 2)
<lfam>I'm not sure when POSIX gained `test -n` but it must have been relatively recently, because the other way appears a lot in old scripts
<nitro_>interesting insight
<lfam>Or, those old scripts don't aim to support POSIX
<lfam>You might dig up any discussion of this script from our mailing lists. I wouldn't be surprised if there is a reason discussed there
<lfam>Maybe also there is some tricky distinction between "$TERM is empty" vs "$TERM is unset"
<lfam>It's never simple with the shell
<lfam>That would explain why the dummy text is 'set'
<lfam>I think that's it
<lfam>For example, take an unset variable foo
<lfam>[ "${foo+set}" = 'set' ] && echo true || echo false
<lfam>[ -n $foo ] && echo true || echo false
<lfam>I believe those will give different answers
<nitro_>i ran a few tests and as long as the variable is quoted, i couldnt find a difference, excpet if you lood it 10000 times using -n was slightly faster
<nckx>lfam: No.
<nckx>test -n "$TERM" would fail after ‘set -u’. "${TERM+set}" would not. However we don't use set -u.
<nitro_>wow, except* loop*
<lfam>I see, the quoting makes a difference
<nckx>lfam: Oh, you forgot to quote the second $foo above.
<nckx>Shell ♪
<lfam>Yes
<lfam>I spent some time banging my head on the shell last night
<nckx>There really isn't a difference *if* your shell is POSIX/sane. I'm with lfam that, if there's a reason apart from cargocultation (used in 97% of shell scipts™), it's to work on a shell that's not.
<nckx>lfam: Who broke first?
<lfam>I conquered the shell
<nckx>Hail.
<lfam>Knowledge is power and so I re-learned how POSIX variable scoping for the 10th time
<nckx>*scripts
<db48x>lfam: not all knowledge is power
<db48x>some knowledge is madness
<lfam>Lol yes
<lfam>But unfortunately the madness began with my own choices, and I have no way out except through it
<db48x>:)
<lfam>I "like" to run my laptop with a headless Debian server install, and then sometimes use startx to make it graphical
<nckx>‘You have chosen shell. You lose. Good-bye.’
<lfam>I got a new laptop with two batteries, and my old "protect the battery" shell script needed to be adapted
<lfam>I delayed this work until the batteries ran down all the way
<db48x>did you read Anathem? the Bash man page should be a chapter in the Book
<lfam>Oh man, my 9th grade teacher made us read that book
<nckx>lfam: All the way? Nooo, that made me physically cringe.
<lfam>Later I realized how crazy she was
<db48x>heh
<lfam>Yes, and now the battery capacity is permanently reduced!
<lfam>All this heartache could be avoided if I would just use a DE
<nckx>Indeed, they never break in arcane hard-to-debug ways.
<lfam>Unlike my battery script!
<lfam> https://paste.debian.net/1171403/
<nckx>I'm sure one of the 5 checkboxes still allowed in all of GNOME is ‘protect lfam's battery’.
<nckx>Hm.
<nckx>OK.
<nckx>Wow. I'm so glad my laptop supports tpacpi-bat.
<divoplade>Is there a function to merge two sets of package-arguments? I'd like to add a #:make-flag to a package definition.
*lfam googles tpacpi-bat
<nckx>Or y'know, $ acpi.
<divoplade>I have used the pedestrian way
<nckx>Although I haven't tried it with 2 batteries.
<lfam>This script has been evolving since "my first linux"
<nckx>lfam: It's not quite what I thought your script did before I read the whole thing. Charging thresholds/limits, really.
<lfam>Right
<lfam>It's really just to prevent me from discharging the batteries all the way
<nckx>Yours is more ‘go look for an outlet, human’.
<lfam>Yeah
<nckx>Hard to automate.
<lfam>And yet every desktop on every OS automates it!
<nckx>That's not the part I meant. :)
<lfam>The i3-nagbar is suuuper hard to ignore
<mroh>ne1 knows how to get the webrtc gstreamer plugin working? `gst-inspect-1.0 webrtc` -> No such element. It seems to be in gst-plugins-bad somehow, but not as a gstreamer module (which are in lib/gstreamer-1.0), but as a sharedlib with pkgconfig etc (in /lib).
***catonano_ is now known as catonano
<apteryx>lfam: you are aware there's such an example in the Guix manual?
<apteryx>A mcron job named %battery-alert-job, in info '(guix) Scheduled Job Execution'
<lfam>I forgot about that! I should use it on my Guix System laptop
<vagrantc>well, couldn't figure out how to trick the debian package to use the system guile instead of bootstrap-guile and various other bootstrap-* bits, but ... i've essentially disabled ~150 tests ... we'll see if i missed anything soon
<vagrantc>it's particularly annoying when tests/*.sh fail; it seems to not bother to run all the other tests in some cases, then.
<vagrantc>hrm ... or a test backtraces and leaves no meaningful log :/
<apteryx>vagrantc: are you running the tests in parallel? that's known to cause problems
<vagrantc>apteryx: i'm running the tests without access to bootstrap binaries :)
<vagrantc>apteryx: parallel doesn't seem to change the results, from what i've seen ...
<vagrantc>and i was assured that running tests in parallel was also supported
<vagrantc>for guix...
<vagrantc>apteryx: tests mostly pass fine if i let it download random stuff from the internet
<vagrantc>well, guix is pretty particular about what it downloads, but still ...
<apteryx>vagrantc: there's an issue in our tracker about parallel tests being broken
<vagrantc>oh.
<vagrantc>well then, i shall run them not parallel, then :)
<apteryx> https://issues.guix.gnu.org/21097
<apteryx>it seems about ARM, but I wouldn't be surprised if it now fails also on x86-64
<apteryx>janneke: would you happen to know if Hurd is able to boot from an image using a GPT partition table?
<apteryx>I guess it doesn't need to know! If the bootloader was able to
<DarjN>It's been two hours and gcc still hasn't been built
<vagrantc>DarjN: that is not entirely surprising ...
<vagrantc>DarjN: though maybe you aren't getting substitutes?
<DarjN>I don't know I left it while I did other stuff
<DarjN>I guess this builds it from source. I'm too spoiled by dnf and apt
<DarjN>wait will this thing also build icecat or libreoffice straight off the installation?
<vagrantc>arg. I inverted the tests for shells
<vagrantc>DarjN: it only builds from source if no substitutes are available or substitutes are disabled
<DarjN>I just went on defaults
<DarjN>no idea how it decides that there aren't any
<vagrantc>DarjN: well, depending how you installed it, it might not be enabled... hard for me to guess what your situation is
<vagrantc>DarjN: though i would say substitutes are normally enabled through most installation methods... i think.
<DarjN>so they're not downloaded, they're in the local install?
<DarjN>the subs?
<vagrantc>they're downloaded from substitute servers ...
<vagrantc> https://guix.gnu.org/manual/en/guix.html#Substitutes
<vagrantc>have to go, but maybe that will help you
<vagrantc>other people might be around, too
<vagrantc>DarjN: good luck!
*vagrantc waves
<janneke>apteryx: not sure, i do know that there is still a 128GiB partition size limit: https://www.gnu.org/software/hurd/faq/2_gib_partition_limit.html
<Loker32>what System requirements? cpu? ram? Storage?
<SebPastor>Hello guys ! I am very new to GUIX. I ve installed in over Alpine Linux my daily driver.
<SebPastor>So far so good ! I had one question though. Trying to install an upgrade of Chromium, I have the feeling that the package is being build while I have authorized substitute
<SebPastor>I am expecting binaries only. Or maybe it is not always the case ?
<brown121407>SebPastor, the substitutes may not have been yet built on the build servers. You can check their availability with the "guix weather" command
<SebPastor>Thanx brown121407 ! Does it mean that if I installed using a local build my next upgrade of the same package will need to be built as well?
<brown121407>Nope, as far as I know. Whenever you tell Guix to upgrade or install stuff it first checks for substitutes. If the next time you want to upgrade the package it is available from the substitutes server, it will be pulled from there, regardless if you previously had to build it
<SebPastor>thx ! it clears things a bit. I have another quiestion (sorry I am just discovering the Guix world). I am confused about which GUIX_PROFILE I should use
<SebPastor>as sometimes the guix command hint refers to ~/.guix-profile
<SebPastor>and other times it points to ~/.config/guix/current/
<brown121407>SebPastor, my GUIX_PROFILE points to ~/.guix-profile, but I use Guix System. I don't know how it should be on foreign distros.
<SebPastor>thx again .. maybe the hint is hard-coded and not suitable for when used on foreign distros then .
<brown121407>I have a Fedora install with Guix on it somewhere, I'll try to install some stuff on it to trigger those messages a bit later. If I discover something and no one has cleared this issue untill then, I'll ping you.
<db48x>SebPastor: it's my understanding that the guix command should come from ~/.config/guix/current and everything else you've installed should be in ~/.guix-profile
<SebPastor>Very nice of you brown121407
<SebPastor>db48x: yes that seems correct ..when looking at the content of the folder. still not sure where to point my GUIX_PROFILE. In the doc (Binary installation) it points to ~/.config/guix/current
<SebPastor>but guix pull commands hints to point to ~/.guix-profile
<db48x>I think it has to be ~/.guix-profile
<db48x>but I can see in the docs:
<db48x>guix.texi
<db48x>693:# GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \
<db48x>2686: GUIX_PROFILE="$HOME/.guix-profile"
<db48x>2755:GUIX_PROFILE="$HOME/.config/guix/current/etc/profile"
<db48x>3044:GUIX_PROFILE="$HOME/.guix-profile" ; \
<db48x>that it's not confusing at all :P
<SebPastor>Well ... now I just re-run a guix pull to try to make a point :) but it gives me 'hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/home/spastor/.config/guix/current/bin/guix'.
<SebPastor>'and funny enough if I run guix pull, the hint I have is
<SebPastor>... something's odd in my setup
<civodul>Hello Guix!
<jonsger>hello Ludo
<SebPastor>the other pb I am facing as newbie, is : just installed qutebrowser ok tried to upgrade it. Now qutebrowser is broken. (I guess the package is faulty somehow). I tried to install previous version but it seems the only version available is 1.14 the latest
<SebPastor>Tried to rollback .. but qutebrowser remains at the latest version.
<SebPastor>Probably a lack of understanding from my part.
<g_bor[m]>hello guix!
<janneke>hello g_bor[m]!
<brown121407>SebPastor, i think you can install previous versions of packages using the time machine. I haven't used it yet, so I don't know more
<SebPastor>ohoh time machine ! :) un new concept. Thx. I will have look in the docs
<brown121407>Inferiors work too, but they seem to be more appropriate if you're building your profile from a manifest
<vits-test>MSavoritias[m]2: re: config.scm error https://paste.debian.net/1171428
<vits-test>
<SebPastor>I ll think I ll take a step back and start a fresh install ... thx for your help all
<divoplade>Hello! How do I tell guix that I have a static IP? I have 192.168.1.10 and 2a00:xxxx::10
<divoplade>The static-networking-service does not seem to accept both
<jonsger>divoplade: what does he say? like an error message or only silently doing nothing?
<divoplade>If I have both, I get: guix system: error: service « networking-eno1 » fourni plus d'une fois
<divoplade>If I only have the 2a00:xxxx::10 address, I get guix system: warning: exception interceptée pendant l'exécution de « start » sur le service « networking-eno1 »:
<divoplade>In procedure inet-pton: Bad address
<divoplade>Of course, the IPv6 is most important to me because it has a PTR record
<vits-test>divoplade: roptat solved it temporary by invoking some things as a service, afaik
<divoplade>I could do it by clicking the network manager applet
<vits-test>(two addresses on same interface)
<divoplade>But I don't want to keep gnome around
<vits-test>+1
<divoplade>Especially the power management service
<divoplade>It shuts down my server!
<divoplade>(well, it puts it to sleep)
<vits-test>divoplade: IDK how service working, but in Guile it is (inet-pton [AF_INET|AF_INET6] "address"). static-networking in gnu/services/base seems to just use AF_INET (ipv4).
<vits-test>static-networking-shepherd-service ... (let* ((addr (inet-pton AF_INET #$ip))
<vits-test>(and no "INET6" in whole file, btw)
<divoplade>For now I keep network-manager with my manual configuration.
<divoplade>I hope it survives reboots ^^
<vits-test>hahahaha.. it should, last time i tried nm.
<jonsger>does someone uses PGP in icedove 78?
<civodul>leoprikler: hey! did you have a chance to look at those GLib patches? https://issues.guix.gnu.org/35594
<abcdw>o/
<civodul>hi!
<leoprikler>My hardware is too weak to thoroughly test GLib in a VM, sadly
<jonsger>leoprikler: then go bare-metal ^^
<leoprikler>perhaps next time my graphics card acts up and decides to kill elogind for no apparent reason :P
<abcdw>My first patch was accepted!) Thank you everyone for help!
<mroh>\o/
<brown121407>abcdw, congrats
<civodul>yay!
<divoplade>What is the package that provides sbin/ip?
<jonsger>divoplade: iproute2
<divoplade>Thank you
<divoplade>So for my static ipv6 I added a shepherd service that runs ip address add dev eno1 2a00:xxxx::10/128 and ip address delete dev eno1 2a00:xxxx::10/128
<divoplade>And it works.
<jonsger>divoplade: I think you can file a bug report, static-networking-service should support that...
<divoplade>OK
<divoplade>Done
<civodul>static-networking-service was waiting for netlink bindings to address that
<civodul>but now that roptat has implemented it, it should be doable!
<efraim>'guix weather -c 100' doesn't seem to like checking against multiple substitute urls
<efraim>would we rather skip building static libraries or put them in a separate output?
<roptat>hi guix!
<efraim>hi!
<jonsger>efraim: I would rather skip it. If someone needs it, it can be added as output again...
<efraim>not always as easily said as done. I was going to test newsboat with a libcurl static library. I know I can inherit it and change it but I wish it was already ready :) Although I do like not needing to download it anyway for grafting all outputs.
<user_oreloznog>roptat: congrats for the translation of the guix-manual and others! I will help again when I have more time
<roptat>user_oreloznog, we always need help proof-reading :)
<user_oreloznog>;-)
<mbakke>efraim: why are you building newsboat with a static libcurl?
<efraim>I haven't been able to connect to disroot's next cloud reader app since april on my computer, same on debian, no issues on my phone
<efraim>debian also uses shared libcurl
<efraim>no clue about my phone
<vits-test>mother's iphone received updates today. "if U don't agree with license terms, do not use this device, and do not download the updates". brilliant. she even not owns the device in the end.
<vits-test>if only it was easy to just swap the ios with some os.
<nckx>Good morning, Guix.
<vits-test>o/
***rEnr3n_ is now known as rEnr3n
<db48x>has anyone here added patches to a package before? my patch doesn't seem to be getting applied when I expected it to
<db48x>the patch changes a file that gets included in the Makefile.am, but the resulting Makefile doesn't have the change
<db48x>suggesting that the patches are applied after autoconf is run
<vits-test>db48x: `git grep search-patches` ?
<vits-test>the patches are in gnu/packages/patches
<db48x>vits-test: yes, the patch is found and applied
<nckx>db48x: First, are you sure that autoconf etc. are being run? If the package contains a Makefile.in it won't be regenerated.
<db48x>nckx: ah, that could be it
<db48x>let me check
<db48x>nckx: that _is_ it
<db48x>thanks :)
<nckx>:)
*vits-test noted
<db48x>nckx: and now all the tests pass!
<nckx>Wewt.
<nckx>db48x: What is it?
<apteryx>janneke: thank you. A asked in #hurd.
<apteryx>I*
<db48x>nckx: https://issues.guix.gnu.org/44576
<apteryx>janneke: I'm asking because I was toying with migrating disk-image generators to use a GUID partition table (GPT) instead of MBR/ms-dos.
<apteryx>But genimage seems to be generating a hybrid GPT/MBR, so it would probably work for Hurd even if it doesn't know GPT.
<nckx>db48x: Thanks! You still need to register the patch file in gnu/local.mk (see its git log) in the same commit.
<db48x>that figures
<nckx>While you're at it: the hack itself is 2clever4me, a brief explanation of how it works in the patch file's #comment would be nice here.
<db48x>hmm, ok
<zzappie>Hello Guix!
<nckx>I mean, I would've expected to have to do more than you did. I'm looking at the patch without context though.
<nckx>o/ zzappie.
<zzappie>Hey nckx
<vits-test>o/
<vits-test>
<db48x>nckx: how is this?
<db48x># This is a hack, but it's easier than trying to decypher sed's build
<db48x># system. require_selinux_ checks the contents of CONFIG_HEADER to
<db48x># see if sed was configured to support selinux; if it cannot find the
<db48x># header, then it bails out with an error.
<PotentialUser-43>Hello, someone please package https://www.liberty-eiffel.org/
<nckx>db48x: Now even I understand it ☺
<db48x>:)
<zzappie>PotentialUser-43: You can submit it to guix wishlist
<nckx>PotentialUser-43: Thanks for the suggestion. There's a wish-list at <https://libreplanet.org/wiki/Group:Guix/Wishlist>.
<PotentialUser-43>Thanks
<vits-test>(zzappie? nckx) ; compiles
<vits-test>waiting for result.. on powerful aarch64
<efraim>I think I fixed sbcl-cffi-libffi on aarch64 and armhf
<nckx>PotentialUser-43: However! Don't get your hopes up. By far the most effective way to get something packaged in Guix is to start yourself. If you get stuck, post your work to guix-devel@gnu.org. People are far more willing to help you than to work for you.
<zzappie>vits-test: :)
<nckx>People don't tend to sit around waiting for ‘ideas’ to package. No shortage of those already.
<zzappie>I may say a confusing thing but is there away to spawn a service within a service?
<zzappie>eg I want aservice that reads config on mounted filesystem or linklocal address api and then spawns static-networking-service
<leoprikler>zzappie: Not without some major hacking, but you can write arbitrary guile code into (start )
<efraim>you can have a service depend on another service, or use an activation service for your service
<zzappie>leoprikler: I see. I just thought there might be a standard that I didn't find in the manual.
<zzappie>efraim: but then I need to edit static-networking-service to include dependency
<efraim>what if you added a new service which you put in the activation service and then for the main service you just called the static-netowkring-service with your new variables
<db48x>nckx: thank you for the feedback
<zzappie>efraim: Hmm.. I understood the activation part, but didn't quiet get what you mean by calling the service. Cause my initial question was how do I call a service within a siervice :)
<zzappie>You mean try to run it in (start ) expression like leoprikler sujested?
<zzappie>*suggested
<vits-test>db48x: why sed-inplace-selinux-test.patch replaces sed-4.8/testsuite/inplace-selinux.sh with sed/testsuite/... ?
<vits-test>(is it works?)
<efraim>tjere
<efraim>there's a way to grab build phases from other build systems and use those, there should be a way to refer to a different service and call it when needed
<db48x>vits-test: ah, that's a good question. earlier in my attempts to fix it, I was going to be patching Makefile.in, which isn't checked into the git repository
<db48x>the easiest way to create that patch file was to diff between a clean copy of sed in one directory, and the edited version in another
<db48x>I guess I didn't think to revise my automation when I decided to just modify inplace-selinux.h instead
<zzappie>efraim: are you making an asumption that there should be a way to do this or proposing a feature?
<efraim>i'm assuming that it should be possible
<zzappie>efraim: ok now I get it tnx :) Trying to figure out. Was postponig reading shepherd manual for too long
*vits-test <fat>jjjust do it. yesterday U said tommorow.. do it!</fat>
<vits-test>btw, a service that manage services, will it be called McShepherd?
<nckx>vits-test: It works since the first element is thrown away (-p1). Many patches even use a/ and b/. The name doesn't matter, although it may trigger column-based OCD ☺
<zzappie>vits-test: dmdmd
<nckx>vits-test: Insheption, shurely.
<vits-test>nckx: ha, i'd forgot it.
<nckx>Oh no, I didn't know this was already fixed.
<vits-test>zzappie: "Do u Mind a Duel on Machetes, Dude?"
<vits-test>(most probably translation in context of Free software)
<nckx> https://1.bp.blogspot.com/_UzyPc4v1wVs/RiBEBKA-OAI/AAAAAAAAAAM/o9Z8t6lldRw/s400/rms.jpg
*zzappie din't get the joke
<nckx>I don't get vits-test's jokes half of the time, just roll with it.
<leoprikler>Just demand trial by combat, that usually works (if you're the protagonist).
<zzappie>vits-test: Shepherd used to be called dmd which stands for daemon managing daemons
<leoprikler>so you made a backronym for dmdmd?
<zzappie>leoprikler: yeah this was answer to the question how "service that manage services, will it be called"
<leoprikler>Ahhh
*nckx .oO ‘Hmm, must I really bloat my minimal Debian with nscd just to run Guix?’ *sound of a thousand errors* ‘...okie then.’ This manual thing, sometimes it has a point.
<nckx>...actually, it still fails to download anything even with nscd running. Odd.
<vits-test>zzappie: Good to know i was mistaken translating that dmdmd. I've no university diploma, and have no right to fight on a duel with weapons dedlier than a pillow.
<vits-test>(and the damned pillows aren't cheap!!!)
<vits-test>nckx: is the time correct on that minimal install?
<nckx>Errr. Whut. kdig +short ci.guix.gnu.org aaaa → ""
<nckx>We're seriously IPv4-only?
<nckx>This box has no v4 IP.
<db48x>nckx: heh
*nckx makes aaaa noises.
<nckx>Yup, berlin can't IPv6 out. No wai. I'll have to reconsider everything... again... 😛
<divoplade>How do I know what file in the store corresponds to the current config file for a service?
<divoplade>OK htop is a good solution
<civodul>or "herd status thing", and then "cat /proc/PID/cmdline | xargs -0 echo"
<nixo_>Hi guix! I'm playing with guix deploy (and it's wonderful) but sometimes the error is really uninformative: guix deploy: error: failed to deploy my-device: ~A: ~S
<nixo_>might it be a missing (format)?
<vits-test>can it `guix deploy --bruteforce debian.dad.local`?
<leoprikler>nixo_: the problem lies with guile error reporting. unusual errors don't get the format treatment and it's hard to make them receive it
<nixo_>leoprikler: ok, thanks
<zzappie>nixo_: are you using ssh or digital-ocean deployment? Just curious I had same problem with digital ocean one last time I used it
<nixo_>zzappie: ssh
<zzappie>okay
<civodul>nixo_: could you report a bug, possibly with a reproducer that forces a failure?
<apteryx>it's funny that man grub-mkimage refers to 'info grub-mkimage', but that this opens the same manpage.
<leoprikler>It's an elaborate plot
<janneke>apteryx: looks like an upstream bug; grub-mkimage is not documented in the info pages
<apteryx>same for grub-mkstandalone
<joshuaBPMan>Hey guix people!
<maav>hi!
<nixo_>civodul: sure!
<maav>one question, is it intended that the ltmain.sh from libtool contains a store path?
<apteryx>hmm... a standalone grub core.img, with all its modules, compressed with xz, takes 1.6 MiB, but the maximum size allowed for the i386-pc (bios) format is 491520 bytes.
<apteryx>there goes the idea to stuff everything in a GPT Boot Partition
<nixo_>is it fine to use (load "something.scm") in the config? That way it seems that the provenance is incomplete
<joshuaBPMan>apteryx may I ask what you are hoping to "stuff in the GPT Boot partition"?
<apteryx>GRUB
<apteryx>GPT Boot Partition is also known as the bios-grub partition
<apteryx>that 1 MiB partition you need to create on a GPT formatted disk
<apteryx>(when using legacy BIOS machines -- UEFI machines would rather use a complete standalone GRUB in the ESP partition)
<joshuaBPMan>Ahh, so basically grub is becoming too BIG for BIOS machines?
<joshuaBPMan>BIOS only machines*
<apteryx>no, it's just that it needs to be kept as a three stages bootloader instead of one two -> boot.img in MBR -> bios-grub -> /boot/grub/* from root file system (on Guix)
<apteryx>I was hoping to cut the last hop
<apteryx>which would have streamlined the disk image code a bit
<apteryx>but it turns out it's not technically feasible. Having a rather large bios-grub partition doesn't change the fact that the machine BIOS will only support loading a file which is at most 491520.
<apteryx>so, let's wait a couple years for BIOS machine to become extinct and revisit the issue ;-)
<maav>apteryx: IIUC, the modules there only have to be the needed ones, and the operating-system object should already have some info like that (partition type, crypto, and so on)
<joshuaBPMan>apteryx I was going to say, please continue to support BIOS machines, but then I remembered that my BIOS only laptop is librebooted, so grub is already loaded in the laptop.
<joshuaBPMan>I think they support grub as a payload in the flash memory.
<joshuaBPMan>maybe the wiki calls it the "ME" flash memory, if my memory serves me right. Man that was a tough weekend project to libreboot my T400.
<joshuaBPMan>I wouldn't have been able to pull it off if one of the main developers hadn't spent 2+ hours coaching me through the process.
<apteryx>joshuaBPMan: coreboot/libreboot support something better than i386-pc
<apteryx>see info '(grub) Core image size limitation'
<joshuaBPMan>apteryx: yes. I
<joshuaBPMan>i'll checking that out.
<apteryx>maav: that could be some way out, but it needs more code :-)
<apteryx>with UEFI remove all constraints but RAM size, it's probably not worth it.
<apteryx>removing*
<maav>hehe
<maav>i tend to be wary of "removing all constraints" in the computer world, because the things usually are finite ;-)
<maav>i have in my TODO list to check that too, the keymap and the .mo files should be included there to have a good boot experience
<maav>perhaps I'll unstreamline it a bit then, i'll try not :-)
<maav>joshuaBPMan: after doing it once, do you think that librebooting another laptop would be easier? or does it have quirks depending on the actual machine?
<joshuaBPMan>maav: If I had to do it again, I would not use a rasberry pi. There is a usb connector thing that you can use instead. (I saw a youtube video that point it out).
<joshuaBPMan>I suppose half of my issue was choosing to use a T400, which involves tearing apart the entire laptop. The T200 is smaller and easier to tear apart.
<joshuaBPMan>And the T200 you only have to remove one part of the laptop. A t400 takes 2 or 3 times longer to libreboot.
<joshuaBPMan>than a t200.
<apteryx>maav: ah, sounds good!
<maav>joshuaBPMan: sounds really cool :-)
<maav>apteryx: it's going to be hard, i've entered into rescue lots of times with past tests, but we'll see :)
<maav>also, having the image generated as a derivation could lead to better detection of when it has to be written to disk during os updates
<apteryx>do you mean in the context of the childhurd service?
<apteryx>or are we still talking about the GRUB image? :-)
<civodul>apteryx: hey! i've been looking at that GLib patch
<civodul>i came up with a new version inspired by yours, found issues, changed it, and then it took me a while to realize it couldn't test it as i wanted because inotify doesn't work over 9p
<civodul>just so you know!
<civodul>so now i need to find another way to test it that doesn't take ages...
<PotentialUser-39>hello, can someone please tell me what to do to solve this error while compiling https://paste.debian.net/1171932/
<maav>apteryx: btw, doing some tests 'grub-mkstandalone --compress=xz --install-modules="luks part_gpt" --fonts="" -v -O i386-pc -o dest.img' could be a starting point, but this depends on the machine where is installed as you can see on the output
<nckx>PotentialUser-39: That file is provided by linux-libre-headers. Is it a native-input?
<PotentialUser-39>what do you mean by native input?
<PotentialUser-39>i'm trying to make this work https://wiki.liberty-eiffel.org/index.php/Getting_Started
<maav>nckx, PotentialUser-39: this is likely the same problem as 43579
<nckx>PotentialUser-39: Oh, I'm packaging that too ☺
<nckx>(Yes, I'm trivially nerd-sniped, point at me and mock.)
<PotentialUser-39>thank, you're a life saver
<apteryx>civodul: hello! I've been working on making it easy to run 'guix system disk-image' on the examples we have that rely on the bootloader-efi-grub, but I'm still having a problem. In the meantime you can hack the os definitions manually to 1) switch them to use bootloader-grub 2) remove the EFI file system
<apteryx>then disk-image -t qcow2 should give you something to play with in a reasonable amount of time
<nckx>PotentialUser-39: Well, we'll see. The reason I'm packaging it is ‘hm, I've never actually seen Eiffel, I wonder if it's fun’ so if things get hairy I might not get far.
<apteryx>but the --image-size doesn't work at least with qcow2 it seems, so you'll have to to with what it gives you ('guix install emacs-no-x' worked for me).
<nckx>PotentialUser-39: What do you have working so far?
<PotentialUser-39>got stuck with that error
<nckx>But at which stage of packaging?
<apteryx>civodul: is there a way to add a ,trace directive *in the code* ?
<PotentialUser-39>hadn't started packaging, got the tarball, ran the install script to just get a feel & hit a wall
<civodul>apteryx: the bootloader and EFI file system is something virtualized-operating-system should take care of
<civodul>but perhaps the new image API doesn't use it
<civodul>we should harmonize that
<civodul>but ok, thanks for the hint!
<civodul>and no, no way to add ,trace inside the code
<civodul>well, there must be a way if we search through the relevant code
***card.freenode.net sets mode: +o ChanServ
<apteryx>civodul: but disk images are for anything, not necessarily for virtualization
<apteryx>A command line option could be added to do the transformation, though.
<apteryx>actually, no, that's already the use case for 'guix system vm-image', I believe
<apteryx>eventually vm-image should be made to use the new disk-image API to make it as performant as we can
<civodul>apteryx: yeah i think mothacehe's plan was to deprecate vm-image eventually
<civodul>i'm frustrated because i wanted to be done with it today so people can test again
<civodul>oh well, maybe tomorrow!
<nckx>Good night, Guix.
<civodul>o/
<maav>bye
<maav>i'm going too, have a good night/day :)
***penguwin3 is now known as penguwin
<apteryx>civodul: I feel you!
<roptat>so I just had a chat with opam folks, and the author of opam2nix :)
<roptat>that was great, and i think I understand how opam2nix works now
<roptat>it's both an equivalent to our importer, and a build-side ocaml library that uses opam to build packages
<roptat>Tim doesn't use it to import packages inside nix-packages, it's only used as a way to "snapshot" the opam repository and build the dependencies of a package with nix instead of creating an opam switch
<roptat>so I'm thinking we could package opam2nix (at least the build-side part) and use it in the ocaml-build-system. That way, I think it will make the importer work a lot better (less need to manually fix packages, since we would use the "source of truth" which is the opam file, instead of trying to guess the correct sequence of commands)
<roptat>once we have this, we could also have use the importer to generate a manifest, or import a build environment from an opam file dynamically, without using the packages from guix
<roptat>though that's a bit risky, as we would not be able to check the licenses, and everything
<civodul>roptat: yeah that brings us to the more general topic of invoking importers "on the fly"
<civodul>which i think could be interesting but has caveats
<civodul>i think it's something we should look at from the POV of importers in general
<civodul>could be fun!
<apteryx>I don't have context, but isn't it a bit scary? Too much automation obscuring what's going on, ala nodejs
<civodul>right now there's the curated distro we provide and the wild west of pip, cargo, opam, etc.
<civodul>the former is obviously great, but it doesn't scale
<civodul>so the "dynamic importer" could be a way to provide something "in between"
<civodul>there are probably many cases where it wouldn't work anyway, for instance because the upstream repo has incomplete dependency info
<civodul>food for thought!
<civodul>in Nixpkgs, they have a bunch of foo2nix scripts, which are like our importer
<civodul>*importers
<civodul>but they just run them periodically to generated an unreviewed Nix file that contains everything
<apteryx>civodul: seems I've managed to fool the store cache with a disk-image, by editing the operating-system definition
<civodul>the store cache?
<apteryx>some detail in the chain of dependency failed to trigger a fresh build of a disk-image
<apteryx>it reused a previously cached build result instead
<roptat>in any case, I'm interested in opam2nix, because it can help us build ocaml packages more easily
*apteryx is hopefully just confused
<roptat>(the build-side part of it, that is)
<roptat>although, maybe I can use opam directly? not sure (it'll probably try to create a switch)
<apteryx>what do yu mean by 'opam switch' ?
<roptat>the equivalent of a guix environment, for opam
<roptat>that involves building dependencies, and downloadin them, which is not suitable for guix
<apteryx>OK
<roptat>opam2nix also has an impure part where it imports packages from the opam repository, but since it's written in ocaml, it uses opam as a library to do the dependency resolution directly
<roptat>I don't think it's suitable for our importer, is it?
<apteryx>civodul: or perhaps it works; I've added code that strips the efi file system for the disk-image
<apteryx>and I was testing commenting that out and putting it back; since it seems to work, the resulting OS used in the derivation doesn't change
<apteryx>so that leaves me wondering why the image produced on machine A boots and on the same commit on machine B doesn't.
<apteryx>commenting that out -> commenting the efi file system manually in the lightweight-desktop.tmpl