<vldn>is it possible to disable the creation of man pages while reconfigure? <sneek>Welcome back vldn, you have 2 messages! <sneek>vldn, nckx says: Man pages are built (or not) as part of the package. You can't disable that without using custom packages. <sneek>vldn, nckx says: Ah... perhaps you mean the man page database? That's something else, but also not (currently) optional. <pkill9> guix system could be used as a framework to use to build a linux distribution, since you can use services to build up the system <jeko>pkill9: you mean the bunch of code to create the VM or joining my currently lonely Emacs session haha <pkill9>it will probably be added at some point <pkill9>it's nice that guix system has a separation between the system and user, somewhat like BSD <acrow> /msg jeko If you are still looking for people to try to connect an emacs, I'm willing to give it a try. <jeko>pkill9: awesome ! just let me know when and I will be happy to send you the details <pkill9>i'll have a quick try now if you like <Aurora_v_kosmose>Correct me if I'm wrong, but the guix-pull bug got fixed after all? What was causing it, in the end? <pkill9>ssh'ing into communal server is a cosy way of forming internet communities <apteryx>pkill9: I realized the last patch of the series should propagate libring, not libringclient <apteryx>in case you get an error that dring is not available, it's probably this ***lukedashjr is now known as luke-jr
<lfam>I just realized I've been using an old version of an installed package (sonata), even since I updated our package definition in mid-January. It's because "1.7.0" is considered a downgrade from "1.7b1" <lfam>I know, I should use a manifest <i1l>i think i saw Termux using ipfs. Just installed man-db recently.. and saw ipfs.io/hash. <apteryx>is it possible to have the dbus from guix talk with the (foreign distro) system dbus? <apteryx>nope, the problem was some exec not under bin sbin or libexec I think, which were not being wrapped by the guix pack (with -RR) <lfam>I understand why this decision was made, but it's hard to accept <jackhill>lfam: thanks for pointing that out. I had no idea either. It's thought provoking, but perhaps the generated thoughts are off topic for #guix :) <lfam>It could be said, but if they are on topic for the linux-libre mailing list, I think they are on topic for Guix, as we use linux-libre <lfam>I am the person that maintains our linux-libre packages, and I think it's wrong to hide these issues <lfam>I don't really have anything else to say about the conundrum <lfam>It's definitely not an easy choice <lfam>Correction, that's not the linux-libre mailing list, but info-gnu, where all GNU projects make important announcements <jackhill>lfam: indeed. My thoughts were spiraling out to the bigger policy of peripheral firmware (of course the CPU is not a peripheral ☺) and while it made sence, the whole "it's okay if it's in ROM" I don't think as been very sucessful in advancing freedom. And here's where I think it might start to get off-topic or at least something I wasn't sure if I wanted to get into, but I wonder if recent events will <jackhill>result in new ways of dealing with the firmware problem. <lfam>Could be, but I think it would take a long time to see a change. And the change I have in mind would be the development of freely-licensed firmware replacements, but that's not an option for this particular topic <lfam>That's because these updates must be cryptographically signed by the vendor <lfam>It's really a thorny subject <lfam>Perhaps best discussed over a beverage <lfam>It can re-grow the tree over and over again, different every time <samplet>Neat! But it kinda looks like a boat. :p <lfam>Well, it has a couple different options for the pot <lfam>It's more tree-like when you watch it grow :) *samplet Types guix environment --ad-hoc cbonsai -- cbonsai <samplet>It looks better in colour, but it’s not growing. :( ***iyzsong-- is now known as iyzsong-w
<lfam>I also recommend --infinite, so it keeps growing over and over again. And also --message <lfam>I'm running it in `urxvt -bg brown`. That's a good background color on my laptop's monitor <lfam>I think the random seed is based on current time, by second, because if two of them start at the same moment, the same tree grows <raghavgururajan>sneek, later tell lle-bout: I have been getting "waiting for locks or build slots..." during offload, for past six hours. Just letting you know. <rhou[m]>I dont yet fully understand the difference between `inputs` and `propagated-inputs` in package definition, I created a package that is depending on a shared library from another package, I had to put this shared library package into the `propagated-inputs` for my new package not complaining about missing library when using it in a development project. Is this correct usage of `propagated-inputs`? <xelxebar_>rhou[m]: `inputs` just means that the package needs those packages to run. Guix will make sure those packages are included in the store when you install the package. `propagated-inputs` are packages that need to be installed in the profile *along side* the package---think Python dependencies or some such. <iyzsong-w>rhou[m]: no, put the shared library in `inputs` of your new package should word. `propagated-inputs` are `inputs` for package A, and when package A is a input for package B, then all package A's propagated inputs (also recursively) become inputs to the package B too. <iyzsong-w>for build package A, it's `inputs` and `propagated-inputs` are same. the propagatation only matter when package A is used as a input for another package. <rhou[m]>iyzsong-w: but why was it then complaining about missing library when in `inputs`? <rhou[m]>But at least it is clearer now how `propagated-inputs` work, it is really on the level of guix packages <nckx>rhou[m]: When exactly do you get the error and what exactly does it say? <nckx>If you're unable to build software with library A normally without always including library B, it's customary for A to propagate B. For example when A's pkg-config file ‘Requires:’ B. <nckx><Guix will make sure those packages are included in the store when you install the package> Not quite. It will make sure they are when you *build* the package from source. Subtle difference. <rhou[m]>nckx: I imported a haskell package from hackage which depends on `librdkafka`, when I build a haskell executable with `runghc` when importing this package I get library not found error, I will check for the exact error... <nckx>*inputs fields are ignored when installing packages. ***apteryx_ is now known as apteryx
<nckx>I'm not a Haskeller, but propagation seems to be almost unused there. <nckx>rhou[m]: Could you patch ‘the haskell package’ (which one?) to refer to librdkafka with an absolute /gnu/store file name? That's ideal. <rhou[m]><nckx "I'm not a Haskeller, but propaga"> yeah thats why I found it strange <nckx>Well, it is a dirty hack, so if there's any way that you can get away without it (see example above), that's good. <rhou[m]>the package is called hw-kafka-client <nckx>rhou[m]: Does it use the static librdkafka.a or the dynamic librdkafka.so? My vote's with iyzsong-w: make librdkafka a regular input, and have all users of hw-kafka-client explicitly include libhwkafka. These are Haskell binding's for a C library; I think it's OK to expose an ‘implemention detail’ like that, especially if it avoids propagation. <nckx>That's probably subjective :) <rekado>for GHC we can do without propagation because GHC installs a package database and uses that instead of environment variables to find dependencies. <nckx>Is that also the reason so many inputs are native? <nckx>I didn't even find how hw-kafka-client dloads libhwkafka (if that's what it does). <rekado>nckx: I don’t know about the native inputs. It’s possible that the use of native inputs is just a mistake, which hasn’t been a problem because we don’t generally cross-build Haskell things. <nckx>Heh. ‘Oops, it was just a typo in the importer.’ <nckx>Bad http-version header component: `ù_ù *nckx tries updating their daemon. <civodul>now, Guile is right that it's a bad header component *civodul dislikes bad header components <nckx>Bad http-version header component: IZ]È22óò[Ûà\ß³ÉkËI½prÕ <zjgkkn[m]1>Hi! can't run 'guix pull' under non root user. Following error has occurred: <zjgkkn[m]1>guix pull: error: Git error: object not found - no match for id (..) <nckx>zjgkkn[m]1: What is that ID? <nckx>Are you using a custom channels.scm? Does ‘mv .cache/guix/checkouts{,.bak}’ fix it? <civodul>leoprikler: i think it is, so we'll see if nckx confirms that was with an older version of the daemon <zjgkkn[m]1>nckx: yes, moving the checkouts dir fix it! Thank уou! <nckx>civodul: It probably predates the fixes (it's the Overdrive to which I regained access today \o/). I'd only ever seen ‘eof’, though, not season highlights from the Unicode test suite. <nckx>zjgkkn[m]1: If you don't want to ‘investigate’, go ahead. <rhou[m]><nckx "rhou: Does it use the static lib"> It is using the dynamic librdkafka.so. What do you mean by explicitly including libhwkafka? <Fodera>the guix manual says that most packages are reproducible, is there a way to check which packages aren't? <xelxebar_>Fodera: The brute force way? Just build a package with --check. <apteryx>hmm, dbus doesn't lend itself too well for 'guix pack', at least the setuid helper thing that requires things to be at /etc/dbus-1/ <apteryx>the exact error I'm facing with the 'guix pack' is that the dbus autostart mecanism fails with: 'Could not get owner of name 'cx.ring.Ring': no such name' <apteryx>although that file exists in the guix pack at "share/dbus-1/services/cx.ring.Ring.service" <civodul>apteryx: hey! yeah, i guess dbus apps try to talk to the bugs already running on the host system <civodul>and that one doesn't know about .service files that are in the pack <apteryx>how does it work on Guix System though? <apteryx>does it honor the .service files from under ~/.guix-profile/share/dbus-1/services/ ? <apteryx>the Qt code is opening the session bus with QDBusConnection::sessionBus(), which works on a foreign distributino <apteryx>the part that fails is locating the 'interface', or that .service file mentioned earlier <civodul>apteryx: connecting to the session bus works; the problem is that the session bus doesn't know about the .service files you're briging with your pack <civodul>and the dbus-daemon program of the foreign distro doesn't know about ~/.guix-profile <civodul>(that of Guix doesn't either, actually) <nckx>rhou[m]: I mean that each user of hw-kafka-whatsit also explicitly includes (inputs `(("librdkafka" ,librdkafka))), nothing more. Instead of assuming that hw-kafka-iforgettherest propagates things. <apteryx>hmm, so that's where the mystery remains for me; I get that the dbus config of the foreign distro probably looks its services at /usr/share/dbus-1/interfaces/; but applications installed on Guix System would only have them under the profile share/dbus-1/services directory; how does the session bus knows about them? <rhou[m]><nckx "rhou: I mean that each user of h"> but I don't understand why guix does not provide the librdkafka shared library when it is listed as a dependency? <luhux>I encountered this error while updating the system, how should I fix it? <nckx>rhou[m]: Provide what, how? What do you mean by dependency? <nckx>* Provide what, when, how? <rhou[m]>nckx: exactly what `(inputs `(("librdkafka" ,librdkafka)))` is doing (having the shaed library `librdkafka.so` somewhere in the search path of `gcc` <nckx>Where is librdkafka listed as an input but not in gcc's search path? <rhou[m]>I put `(inputs (("librdkafka" ,librdkafka)))` in the `ghc-hw-kafka-client` package definition and assume that when including `ghc-hw-kafka-client` package to my environment then `librdkafka.so` file is available too or is this assumption wrong? <rhou[m]>is this only a build time dependecy? <nckx>Yes, your assumption is wrong. You can't specify dependencies in Guix. <nckx>‘Dependency’ is an observation about how software behaves. If you add (inputs `(("icecat" ,icecat))) to the ‘hello’ package, Guix will make icecat available while building hello, but it will never be a dependency of it. It also won't include the store file name of /gnu/store/...-icecat anywhere in /gnu/store/...-hello, so it's not a reference (= the way that Guix decides which other store items need to be built/downloaded when installing hello). <roptat>rhou[m], you need to find a way for ghc-hw-kafka-client to refer to that .so file with its full store path directly, not simply by its library name <apteryx>civodul: I think the problem may be that we have a dbus patch overriding the defaults system places for config to /etc for dbus <apteryx>perhaps it can't find any basic blocks it expects and fail with a misleading error <apteryx>anyway, I'll try a non-dbus alternative for now <roptat>so, if you have something like dlopen("librdkafka.so"), you need to substitute* it to something like (string-append "dlopen(\"" (assoc-ref inputs "libdrkafka") "/lib/libdrkafka.so\")") or similar <roptat>that way, the full path is recorded and guix knows that it's a dependency of your package <roptat>another solution (which brings other issues) is to use propagated-inputs <apteryx>civodul: but basically we should perhaps look into it, as it means that any program relying on dbus autostarting services will fail outside of Guix System <apteryx>I've seen nix often accomodates some kind of fallback for foreign distributions <apteryx>(e.g, look our stuff at first, if not there, try the foreign distro location) <nckx>roptat: That was already discussed, but do you know what that ‘something like dlopen’ would actually look like? I didn't find it, but I don't know what to look for. <roptat>nckx, no, not for that language. I'd grep for "librdkafka" in the sources <nckx>I (still) don't think propagation is worth it here. <roptat>maybe it's a dependency that doesn't contain the reference when it should? <sneek>Welcome back lle-bout`, you have 1 message! <sneek>lle-bout`, raghavgururajan says: I have been getting "waiting for locks or build slots..." during offload, for past six hours. Just letting you know. ***lle-bout` is now known as lle-bout
<lle-bout>raghavgururajan: run: 'guix processes' and kill the stale ones <lle-bout>raghavgururajan: it seems you forgot 'ibus' in 584022bbe1c475ae0c2d11f9b22603d7c06c2306 title <nckx>roptat: I can't parse the last sentence, but ‘extra-libraries’ was the only relevant-looking result for grepping for librdkafka. So it looks like it's all build system magic. I've deleted my source checkout by now. <civodul>apteryx: at first sight, i don't see how dbus activation could work (as in: pick services from ~/.guix-profile) on foreign distros, but it'd be worth investigating <rhou[m]><roptat "so, if you have something like d"> I will try to find if this is applicable, what is the issue with `propagated-inputs`? ***atw``` is now known as atw
<civodul>mothacehe: hey! i noticed that Cuirass disables channel authentication; do you have plans to enable it? <civodul>that'd be nice, especially since the Cuirass instance is going to run the code that it pulls :-) <nckx>rhou[m]: If ghc-hw-kafka-client propagates librdkafka and package A has ghc-hw-kafka-client as an input, installing package A will implicitly install librdkafka, polluting your profile with something the user didn't ask for (they asked for A only) and have no use for (librdkafka's search paths aren't needed to run A). <mothacehe>civodul: hey! yeah I disabled it because I suspect that some users have custom channels with no authentication and "latest-channel-instances" procedure only support authentication if all channels are authenticated. <nckx>rhou[m]: Basically, it makes Guix act like an old-fashioned package manager/distro, where if you install icecat you can suddenly run ‘~$ sqlite’ because icecat uses sqlite internally. <mothacehe>so my plan was to have an authenticate? parameter on a per channel basis in "latest-channel-instances" <rhou[m]><nckx "rhou: If ghc-hw-kafka-client pro"> but ghc-hw-kafka-client does only work with librdkafka so I would argue the user has a use for it <nckx>Not if they installed A. Propagation is transitive. <lle-bout>raghavgururajan: no, port is given with -p with ssh <lle-bout>raghavgururajan: I meant to run 'guix processes' on YOUR machine <lle-bout>raghavgururajan: but you can also run it on the build server <nckx>If awesome-app uses ghc-hw-kafka-client, ‘guix install awesome-app’ will pull librdkafka into the user's profile, which is suboptimal. Having to add (inputs `(("ghc-hw-kafka-client" ,ghc-hw-kafka-client) ("librdkafka", librdkafka))) to awesome-app's definition is suboptimal too but much less so IMO. <nckx>You'll only do that once. <lle-bout>raghavgururajan: pkill works with patterns, use kill for pids <nckx>The ‘p’ stands for ‘not for PIDs’. <rhou[m]><nckx "Not if they installed A. Propag"> ah I see it now <rhou[m]><nckx "If awesome-app uses ghc-hw-kafka"> yeah better explicit then implicit <lle-bout>raghavgururajan: as you arent root on the build vm you can't kill processes unless they are started by the user you have access to there, but I suspect that killing build processes on your machine may be sufficient <lle-bout>raghavgururajan: note there can also be stale locks but don't blindly delete them it could also corrupt stuff <lle-bout>there's no running processes on the build machine besides some environment of marusich <lle-bout>raghavgururajan: great! basically there's SIGTERM handlers when you send regular kill, so that handler may clear locks *raghavgururajan makes a weird noise <raghavgururajan>mercurial tests fail, but --without-tests wont work on it, as it uses custom check phase. <lle-bout>raghavgururajan: use some uncommitted change disabling tests for testing until we figure that out <lle-bout>raghavgururajan: FYI I ran builds of your branch and now I am cycling through security issues then can get back to reviewing <raghavgururajan>gnu-build-system no longer triggers bootstrap when there is no configure file. <lle-bout>I also get locks/build slots problems now, it didnt happen for me before, I just did a system reconfigure hmm <civodul>raghavgururajan: what's the problem? it could be that the changes i made in core-updates broke some packages <civodul>i fixed a couple of them, but lemme know if you notice something fishy <civodul>ah gnu-build-system no longer triggers bootstrap? <efraim>I have a patch for mercurial as part of disabling the tests on powerpc <efraim>oh, nvm, it's already got 'when tests?' on core-updates <efraim>I have a note for 32-bit ppc that it takes more than 10 hours to run the mercurial test suite <civodul>raghavgururajan: i think that "faac" just builds by chance on master; its source file name doesn't end in tar.gz, so it's not getting unpacked at all on core-updates <civodul>also, its source URL should use mirror://sourceforge <civodul>raghavgururajan: could you fix both issues on master? <civodul>it'll be merged eventually, or we can cherry-pick <civodul>weird that 'guix lint' doesn't complain *civodul is the new 'guix lint' <civodul>CaaGLS (civodul as a guix lint substitute) <lle-bout>flatwhatson: hello! do you get some times errors that block Emacs temporarily saying it didnt find some native-comp files? <Noisytoot>Synapse recommends nonfree software in its documentation, but it is in Guix <lle-bout>raghavgururajan: CVE queue finally cleared.. <raghavgururajan>Noisytoot: Is it only the doc or also the code recommends them? If its former, as long as we don't build/include the doc, things should be fine I guess. <lle-bout>I feel like not providing the docs because it recommends some non-free software is a bit extreme, but yeah <lle-bout>We can have different interpretations of FSDG <lle-bout>Yes, maybe patching the doc can be, if people are really willing to do it <raghavgururajan>rekado: Thank goodness you are here. How to fix the useragent in icecat for the CDN? <lle-bout>There's things like this: cat $(guix build synapse)/lib/python3.8/site-packages/synapse/res/templates/recaptcha.html <lle-bout>There, there's a script include with recaptcha <raghavgururajan>Noisytoot: Btw, thanks for your concern and bringing it to our attention. It is important we keep Guix non-free free. Could you please file this as bug report? <lle-bout>raghavgururajan: it seems there's major rebuilds again (rust ..) so <flatwhatson>lle-bout: No, but I use doom which pre-compiles all the things. <rekado>raghavgururajan: I use an extension <lle-bout>flatwhatson: okay, thanks, it may be due to recent issues pointed out in the ML about updating Emacs while it's running, also a question, does C-x-f /sudo::/path/to/file work for you? <rekado>I’m not currently using it, but I had to use it in the past to get around some websites blocking icecat. <tpefreedom>The command to download the gpg keys for the install script doesn't find any. <rekado>tpefreedom: I cannot reproduce this. <rekado>that fetches the key as expected. <tpefreedom>It said that there were not any valid gpg keys for me. *raghavgururajan 's device is boiling, looks `top` <rekado>hmm, the wget command doesn’t say that. They left but I would have suggested running wget first to see if it returns what you’d expect, and then try piping it into gpg. <lle-bout>raghavgururajan: it seems on this one we really do get slowed down by compilation times <lle-bout>raghavgururajan: somehow I feel like we shouldnt have merged the first batch to core-updates, that it wasnt a good idea <lle-bout>The good thing about merging to core-updates is that we get less rebase conflicts since everyone works with our changes, the less good things is that as we are affected by other's problems we are also causing other problems potentially in core-updates <raghavgururajan>lle-bout: That wasn't the cause of rebuilds. The first batch has been delayed for too long. Glad that we merged. <lle-bout>raghavgururajan: not rebuilds I mean, but I have a feeling now most GNOME stuff is broken on core-updates? <lle-bout>raghavgururajan: we must absolutely commit to finishing this upgrade and not giving up otherwise we might leave core-updates broken in ways nobody will be able to fix. <lle-bout>nckx: hello! :-) - Just know that if you can tackle that bug I am encountering on CVE lint colors, I will be able to prioritize all CVE issues reported by 'guix lint' and not feel submerged by them in a way I do none of them and instead only process new ones which come at a pace I can handle. <lle-bout>I have tried looking myself but it seems I don't understand how json parsing works with GNU Guile. <raghavgururajan>lle-bout: Btw, things that break by our updates, we can fix them with the flow of updating stuff. But things that are broken outside of our updates, we definitely need help. Else, it would be very tedious for us. <lle-bout>raghavgururajan: Agreed! On PHP I will see what the error is I can probably fix, GNU Shepherd I don't think so, Mercurial also will look soon when more stuff builds <raghavgururajan>rekado: To take up on your offer, would you be able to help us with shepherd and mercurial? Their build fails in c-u, which is a blocker for our work. <rekado>raghavgururajan: oof, I’d love to help but this weekend I’m helping my relative move and assemble furniture. I’m fresh out of time :-/ <Vongazi>becuase in the maunal it says it is not implemeted yet <leoprikler>If the manual says so, it's likely the case. We very much try to keep our manual updated. <lle-bout>mothacehe: hello Mathieu! I am thinking, is it a good idea to include aarch64-linux now in guix-ci notifications since it breaks so often in random ways due to usage of emulation (I believe?) <lle-bout>mothacehe: I have not been able to rely on those very much to try and fix issues at any point of time for now, like if I were to try and go fix every broken package for example. <Vongazi>leoprikler so is there a way to do it manually because i guess i cant do it from config.scm <mothacehe>hey lle-bout, guix-ci notifications are enabled on the guix-master specification, for all three supported architectures: i686, x86 and aarch64. <mothacehe>but given the problems with aarch64, I'm considering disabling emulated builds for that architecture <Vongazi>i can boot the machine and grub asks me for the passphrase but then the while the machine is booting i get asked for it again but it doesn't find the lvm volume <mothacehe>and only rely on native hw to build the core subset <leoprikler>I don't use luks, so I don't know. You might want to stay around and have someone else help you with your LUKS setup or write a mail to guix-help. <mothacehe>I implemented your pagination suggestion btw <lle-bout>mothacehe: ah super cool! I am going to look at it! And yes I share the same questionning about aarch64-linux emulation <lle-bout>mothacehe: what suggestion have you implemented exactly? <lle-bout>mothacehe: aahhh!! awesome! thanks so much! Also could you make the failure icon a dedicated column so I can order by it? :-D <terpri>Vongazi, i use lvm-on-luks (and wrote my own implementation before guix supported it), i'd be happy to help if i can <lle-bout>mothacehe: failure icon, I am speaking of the arrow and circles <cbaines>civodul, at some point I might try to more elegantly handle these kind of crashes when loading data, but I haven't got around to that yet <terpri>Vongazi, it works perfectly well, probably the documentation is just out-of-date <civodul>mothacehe: hey, i was wondering what you think about the connection between your work and the mythical Scheme rewrite of the daemon? <cbaines>civodul, I'm not sure what the /gnu/store/.*qmlcachegen related error means, I got a different error when trying locally <civodul>cbaines: looks like a regexp, i wonder where it comes from <terpri>Vongazi, sure, i'll post a config snippet <civodul>cbaines: the regexp occurs in the ktouch package definition, but how it can end up here, i dunno <cbaines>civodul, yeah, it's a bit odd. This is the output I get locally <terpri>Vongazi, https://paste.debian.net/1192016/ is an example config. things to note: mapped devices are processed in order (so LUKS comes before LVM), and the file systems they contain should be declared with "(dependencies mapped-devices)" in the file-systems list <terpri>other things to note: the console output on boot is noisy and doesn't stop at the passphrase prompt, so basically you wait until the boot pauses and then type the passphrase. also if you boot from a LUKS device, you must use LUKS1 (still the default) until the next grub release comes out with new LUKS2 support <cantillion>Hello there, I'm trying to get icedove to 'see' my gpg keys, i guix install-ed gpg (currently at 2.2.27), and gpg -K lists my keys fine, but still icedove won't let me choose them. Any idea? <Vongazi>reconfigure it asks if i forgot a use-modules <link2xt>cantillion: icedove no longer uses gpg <link2xt>enigmail used gpg, but now icedove has a built-in implementation with a separate keystore <cantillion>link2xt: thans. I was about to install enigmail, I shall now look first at your link <link2xt>since version 78 enigmail is just an addon which imports all your keys from gpg and proposes to remove itself <terpri>Vongazi, hm... you can try "guix repl" and then eval (@ (gnu system mapped-devices) lvm-device-mapping) <terpri>it should respond with something like $1 = #<<mapped-device-type> [...]> <terpri>if it's unbound, your guix installation might need upgrading (it was added on 2020-11-06) <terpri>if not you might need to import the module in config.scm; i'm not sure what's auto-imported there since mine imports a ton of random modules <terpri>(and i use the stable master branch, rather than staging or core-updates, so it should be available on an up-to-date installation) <apteryx>civodul: do you know if the wrapping done by -RR would mean gnutls should resolve certs from the pack's etc/ directory^ <Vongazi>terpri it still doesn't want to reconfigure i updated gu <Vongazi>guix but it still cant find the variable <lfam>My guess is that there is some confusion about which Guix is being used <lfam>Can you share the exact commands you used to update Guix and attempt reconfiguring? <Vongazi>guix pull, guix install guix, hash guix, guix system init /mnt/etc/config.scm /mnt <lfam>Vongazi: I'm not sure exactly what is wrong, but I see two errors <lfam>First, you should not do `guix install guix` <lfam>If you've done that, please do `guix remove guix`. There's no need to install Guix with itself <lfam>Second, `guix system init` is used to install Guix System for the first time, but not for upgrading it. To upgrade it, you use `guix system reconfigure` <lfam>Finally, I was hoping you'd show us the exact commands, copied and pasted from your terminal. How do you elevate your privileges to use `guix system`? Do you use `sudo`? `sudo --login`? Something else? <Vongazi>i am still installing that is why i used `guix system init` <lfam>We added support for LVM after the most recent release <lfam>So, it's not included in the installer, sorry <Vongazi>because i have data that i can't back up now <lfam>We will make a new release on April 18 <Vongazi>can i update guix that is in the live cd? <lfam>Yes, it is possible to do `guix pull` in the installer, and thus get the LVM support. But, we haven't tested installing Guix System with current `guix pull`, so it may or may not work <lfam>But, you still should never do `guix install guix` :) If you saw something that recommended that, can you say where it is? <Vongazi>thanks i think it is reconfiguring now <lfam>Okay, I asked because you are not the only person who's done it, and we want to understand why people are doing it <lfam>We might make it impossible or, at least, hard to do <lfam>Let us know how the installation goes <terpri>i've definitely done "guix install guix" at some point, imo it's a bit counterintuitive that one shouldn't <lfam>I also did it, but at a time when Guix was significantly different <lfam>`guix pull` has been totally overhauled since then <lfam>I just wonder if there is some wiki or "how to" that is recommending it <lfam>It's interesting, now, after years, I think it's really strange that you'd do it. Like, if you have the `guix` command, why try to install it again? <lfam>But, the understanding of an old veteran is really different to that of the beginner <lfam>It's normal to just try things when the software isn't working the way you want. And it's abnormal to study the docs :) <civodul>apteryx: the -RR wrapper doesn't "map" the host's /etc into the guest <civodul>so the wrapped GnuTLS-linked application should use the host's certificates, in /etc/ssl/certs <civodul>(which is probably what you'd want anyway) <Vongazi>terpri lfam THANKS finally guix installed with lvm on luks <terpri>Vongazi, awesome! i'm glad it worked out :) <brown121407>hi Guix is the best operating system I ever used and I love it and it doesn't make me want to jump out of the window unlike the other OS that starts with "window" just wanted to say this ok thanks <apteryx>I think Jami has quite modern requirements for the certs ***nckx is now known as Thunderbi
<apteryx>civodul: I was hoping that if I add nss-certs to the pack I could control the certs used without the need for root, but meh, GnuTLS and /etc/certs. <lfam>It's unfortunate, but we still are not building the updated manual for the web site <apteryx>so the guix package could be updated and guile-lib is now at 0.2.7? <lfam>If I understand correctly, everything *should* be working now <lfam>I'm not sure exactly "which" Guix is used in this context *lfam looks at the cron logs <lfam>Hm, looks like something still needs to be updated. It's still failing due the incompability with giule-lib <lfam>Looking at the cron logs for building the manuals and cookbook, there are a few guile-html-index-en.drv builds failing <lfam>E.g. /gnu/store/ig7q4fmmmvnlj5p2ffmwvd8ap2izism7-guile-html-index-en.drv <lfam>Maybe we need to reconfigure. The current-system's provenance is based on commit ec3b73336861eaa27f506d17fdbea573363beb84 (March 27) <lfam>I sent some notes to the bug ticket *Thunderbi regained access to dmitri today, reconfigured & rebooted, now it's unresponsive again... sigh. <Thunderbi>Not in any kind of context, but it can really bum one out after an evening like this one :) <lfam>What was required to regain access? Like, do you know why it went offline? <katco>i'm dipping my toes into aarch64. can someone help explain this to me? `guix weather -saarch64-linux gdk-pixbuf` reports `100.0% substitutes available (1 out of 1)`, but then `guix environment -saarch64-pixbuf --ad-hoc gdk-pixbuf` tries to build it? <lfam>katco: And, you do get substitutes sometimes. Just trying to make sure they are enabled <Thunderbi>lfam: Physical access. I had to hard-reset it, then it booted fine (but nothing useful was logged to disc), rebooted a few times, worked fine. Pulling + reconfiguring takes way too long to do in person, unfortunately. <lfam>katco: My first sentence was supposed to have a question mark at the end <katco>lfam: for x86_64, i get substitutes all the time. i've never used guix with aarch64. <katco>lfam: i should mention this is on an x86_64 guix system utilizing the `qemu-binfmt-service` <katco>(i have an aarch64 system i'm trying to offload builds onto) <lfam>Hopefully someone has more questions beyond "are substitutes enabled" :) <lfam>Thunderbi: That's frustrating <lfam>katco: In general, I think substitute delivery is... probabilistic <lfam>But maybe there is an issue with requesting substitutes in this case <katco>i've been trying sporadically all day. unless the probability is really low, i would have expected one of them to succeed <katco>local builds of that package fail for me too, which i don't really understand either <lfam>The first request for a new substitute usually doesn't work, but it triggers the caching of the substitute on the server, and then subsequent requests should work. At least, that's how it used to work, and I still observe that pattern <lfam>But, if you tried it more than once, with more than a couple minutes in between, it should work <katco>yeah, i have definitely expressed that pattern <lfam>Does the local build, like, "fail to compile", or is it a Guix error? <lfam>If you can share the exact derivation of one of these builds, I can check its status on the build server <lfam>Like, `guix build gdk-pixbuf -saarch64-linux --derivations` <katco>hrm... i've not used that before. it seems to be launching into a full build? <katco>`/gnu/store/imh1bc9gv7lwzfvm4mxxrhc8xymsw89x-gdk-pixbuf-2.40.0.drv` <lfam>It has been built on the server <katco>aha! if i build with `--no-grafts`, it downloads the substitute? <lfam>Grafts are performed locally <lfam>It can definitely be confusing <katco>but guix decides what grafts to apply, right? why would my local guix be trying to apply grafts that prevent alignment with guix proper? <lfam>I'm not sure I understand what you mean <katco>yeah sorry that was confusing <katco>so aiui, grafts are guix's way of applying security updates without having to rebuild the world <katco>i have never knowingly told my local guix: here is a graft to apply <katco>so in the simplest terms: why would my guix try to apply grafts differently than our ci? <lfam>Basically, CI doesn't graft <lfam>It only builds ungrafted things <katco>ok, so it's entirely possible for CI to think things are green, when everyone's systems are red due to grafts <lfam>I *think* it builds the replacement packages that will then be used for grafting. Like, I think it builds the replacement openssl-fixed, but then your Guix downloads it and locally rewrites references in all packages that use openssl <lfam>It shouldn't break anything, but it can make development annoying <lfam>I always work with --no-grafts when developing things, and then let the grafting happen when I actually want to install something, or when reconfiguring my system <lle-bout>raghavgururajan: hello, things still building <lle-bout>raghavgururajan: plenty of stuff failed also.. in what it seems really bad ways <katco>lfam: well in my case, i couldn't `guix package -i emacs` on an aarch64-linux system because it couldn't download `gdk-pixbuf` nor build it <lfam>It's just a lot faster that way, and I have a sense of the security risks involved and accept those risks <katco>lle-bout: hey, in passing, thanks for working on gnome 40! <lfam>Yeah, it's definitely a problem that it couldn't build the thing locally, katco <lfam>What kind of aarch64 system are you using? Or is it emulated? <lle-bout>katco: and thank you for showing your interest! raghavgururajan's doing the work and I am mostly reviewing and double-checking their stuff at this point! <katco>lle-bout: i don't use gnome that often, but i wanted to thank the two of you for taking up the cause. it's appreciated! <lfam>That should be more than capable <katco>lfam: yeah, i first tried building it on there, but thought maybe it wasn't capable so i began offloading to my threadripper <lfam>Hm, so a tangled web of offloading, grafting, and a hardware platform that we are unfortunately falling short of supporting as 1st class <katco>well, if you like to simplify: i experience this behavior directly on the pinebook pro <lfam>Can you confirm that it's the same derivation that failed to compile on there? <lfam>This "ungrafted" derivation is the one that built successfully on CI <lfam>If you get a derivation there, you can `guix pull` to the latest. I had just run `guix pull` before checking on things on CI <lfam>I mean, if you get a different derivation there