<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>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
<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.
<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>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?
<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?
<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
<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
<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.
<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.
<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: 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
<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.
<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
<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?
<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`
<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
<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.
<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
<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