<GNUtoo>hi, I also have a question about a patch, I've made a package definition for h-client, and I wonder in which gnu/packages/*.scm to add it
<Zambyte>It is just the one test failing, I will look try to disable that one test instead. If I get it working, should I reply to that patch I sent with the new patch, or make a new thread? I haven't really done e-mail driven git before :D
<iskarian>Zambyte, you would send the mail to firstname.lastname@example.org (where nnnnnn is the bug number you got in your confirmation email), in reply to the original message. With git send-email, if <email@example.com> is the value of Message-Id field of your original email, it would be '--firstname.lastname@example.org --email@example.com'. You would also want to make your patch with '--reroll-count=2' to add a v2.
<GNUtoo>This is the entry on the Thinkpad X200 and we know it works fine in Trisquel 6 at least
<GNUtoo>While it's far from perfect that hardware database works great for peripherals like USB WiFi cards for instance
<GNUtoo>lspci is in pciutils, and lshw is in linux
<GNUtoo>So I wonder if I should add it in linux even if it's not a project made by the Linux community (it's hosted on savanah)
<iskarian>GNUtoo, you might put it in hardware.scm if you don't find a better home
<zeroter>Many times, I've been at this for a few hours now
<zeroter>I also tried adding loadkeys to setuid so I could use it as user, but it only worked if I spawned bash manually, after logging in or entering gnu screen
<zeroter>the keyboard-layout works in login itself though, just not in the shell it runs after logging in. It's so weird and specific...
<apteryx>podiki[m]: mcron logs go to /var/log/mcron.log; you can refer to programs via their store path easily by using ungexp, e.g. #$(file-append some-package "/bin/some-binary") inside the mcron #~(job ...) definition.
***marwan6 is now known as marwan
<podiki[m]>apteryx: ah interesting about the file-append, thanks! I'll have to see what happens before I add that, but that sounds very helpful to have
<apteryx>the only place where it falls short is when wanting to use a non-default output; there you must fallback to plain string-append and #$
<sneek>Welcome back raghavgururajan, you have 1 message!
<sneek>raghavgururajan, podiki[m] says: figured out the xdg-desktop-portal issue, I think it is both a bug with our packages (makes XDG_DESKTOP_PORTAL_DIR multiple directories) and upstream (they should support that); nothing to do with dbus in the end
<str1ngs>raghavgururajan also things like gobject-introspetion patches don't apply anymore same with gstreamer. so not sure how to best tackle this. I think probably starting from the bottom up would work best. glib, gobject-introspcetion -> gtk. then start updating all this core gnome programs.
<raghavgururajan>> str1ngs: raghavgururajan: I think these gtk 4 tests that are failing are X server related. it may be okay to disable them right now. at least nix does too. or the test x server needs tweaking.
<podiki[m]>I just saw this actually. would be good to submit somewhere with guix, maybe help-guix list? or as an issue. I too would like a more detailed (like an api type) ref easily available for when you are starting out with install and getting set up
<str1ngs>the problem is you can't compare guix to other distro's it requires a paradigm shift in thinking.s
<str1ngs>even thing like guix install though they are there to give you the general feel of other distros. it does nothing like apt install .
<podiki[m]>(not sure if you were referring to when I mentioned "install" but there I didn't mean the command but the distro installation/setting up process)
<podiki[m]>but yes, good point about guix install being a different beast really
<clone>SVS: the first child of the linked node has a config example and tells you how to use it. The config file doesn't have a specific location (I put it in /etc/config.scm), and you specify it when you run `guix system reconfigure`
<str1ngs>the other misconception is that config file needs to be located somewhere specific. the file is where you just to have it.
<podiki[m]>I think there is a lot of good stuff in the docs and cookbook, but quickly ran out of helpful examples for some things (and yes, I should submit a patch or report about these things); always better to have more examples and specifics
<podiki[m]>as an example, took me a while to parse different combinations of services, cons, modify-services, and all that; relied on some searching to find people's example configs, which might be nice to have a collection of
<SVS>The problem isn't that the files aren't somewhere specific. The problem is, for people knowing nothing about how it works, where to start. When I'm in a live distro, then the config is somewhere, but I didn't know where to look. Because it's not explicitly explained, which should be like the first line or in the first paragraph of a tutorial. So if I want to change only one little thing, I don't know where to get started. However, I got some infos now. Thanks, I will
<efraim>sneek: later tell lfam I'll have to dig out my go cross compile patch again, I don't remember exactly what it was but something about setting the GOBIN made cross compiling fail. I'll finish up my go cross compile patch and then we can fix cross compiling syncthing later
<sneek>efraim, lfam says: I reverted one of your commits, tracked as <https://bugs.gnu.org/50071>. It was "syncthing: Prepare for cross-compiling". I can try to re-do your change without breaking the outputs splitting if you tell me how to test for what you were trying to achieve in your patch
<jgart>use-package and leaf provide macros with a nicer API/syntax than the vanilla elisp you'd usually write to configure emacs packages. Just leave off the :ensure stuff if you're intending to manage elisp packages only with guix.
<zamfofex>Hello, Guix! I have been playing around with ‘guix pack’, and I noticed that the resulting tarballs include packages such as GCC. Of course, GCC is used to build them, but I don’t think it is used at runtime. Is it really necessary for it to be included like that? Am I doing something wrong? Other unexpected packages include Emacs and Bash.
<zamfofex>I tried extracting the tarball and deleting the seemingly extraneous packages before running the main packed executable, and it still seems to work fine. Is there a reason for those packages to be included by default? Can that be disabled somehow?
<zamfofex>On further analysis, it seems like the packages that are included are ‘gcc:lib’, ‘bash-static’ and a store entry named ‘emacs-subdirs’ (which I don’t know whether corresponds to an actual package or not). I suppose that’s a more reasonable set of packages to include than I thought, but it still feels weird that some C headers are included (from ‘gcc:lib’).
<zamfofex>The ‘emacs-subdirs’ entry doesn’t actually contain the full Emacs, just a few small (configuration?) files. I’m still not sure why ‘bash-static’ is actually needed, though.
<rekado>zamfofex: all those packages are included that other outputs refer to.
<rekado>gcc:lib is a runtime dependency of many things.
<rekado>packages are generally not added for fun; instead Guix scans for references in files.
<rekado>it is possible (and not all that uncommon) for references to be pointless.
<rekado>some packages, for example, install a text file listing programs of the build environment with their absolute file names.
<rekado>that would be a useless source of references
<rekado>but Guix can’t know that it’s useless and proceeds to include all the packages whose outputs are referenced
<rekado>if you identify a useless reference please report a bug.
<rekado>we have some bug reports about icedtea / openjdk that fall into this category
<zamfofex>I understand. That’s all fair enough! Thanks for the explanation. I’m trying to pack a local package that I wrote, the only dependencies it has are ‘stb-image’ and ‘openssl’.
<zamfofex>If there is such a “useless reference”, does the program generally fail to even start? E.g. with a linking error. Unless it links against the libraries at runtime (which is possible for OpenSSL, I imagine).
<zamfofex>I’m slightly sleepy, so don’t mind if I speak some nonsense. What I meant is actually: If the references I deleted before running aren’t actually “useless”, shouldn’t I have gotten a linking error when executing the program?
<zamfofex>Because if so, then I can conclude that either (a) OpenSSL is linking against the library at runtime, or (b) the dependency is not actually necessary.
<zamfofex>Maybe it could make sense to add some kind of “expected references” field to packages, and fail building the package if the detected references don’t match the expected ones. This way, when updating a package, if the references detected change, it’d require (a person) analysing whether that makes sense or not.
<maximed>zemfofex: There is #:allowed-references (list this-package that-package ...)
<maximed>If the store item isn't broken, there is no need to build/substitute anything ...
<maximed>IIRC, the guix daemon keeps the hash of the contents of each store item in a database
<PurpleSym>`guix gc` reports it as broken, but is apparently unable to fix it.
<maximed>Is the store item path returned by "guix build --repair" exactly the same as the store item path reported by "guix gc"?
<maximed>If it's different, it means the ‘coreutils’ packages come from different derivations
<PurpleSym>So, `guix gc` reports /gnu/store/003lvgysgmyxi8hkwcm9qqgc9hm8r4gm-node-14.16.0 as broken, which is a graft of /gnu/store/8dz24zxd1brxxdldqvfg23w4vg97dwq2-node-14.16.0 as far as I understands. It redoes the graft, but on a second run it reports it at broken agani.
<PurpleSym>`--repair` redoes the graft and reports /gnu/store/003lvgysgmyxi8hkwcm9qqgc9hm8r4gm-node-14.16.0. With `--no-grafts` `--repair` does nothing and just reports /gnu/store/8dz24zxd1brxxdldqvfg23w4vg97dwq2-node-14.16.0
<maximed>"guix gc --verify=repair" should do the right thing I think
<PurpleSym>Yeah, it’s finding more and more broken store paths. I’m guessing serious filesystem corruption.
<zeroter>I had a problem with loadkeys/keyboard-layout yesterday. It turns out `/bin/bash` was pointing to the 5.0.6 version, but user had 5.0.16. Forcing the newest bash using extra-special-file solved my problem
<maximed>zeroter: That seems a bug in the "kbd" package. loadkeys shouldn't be using /bin/bash, it should be using /gnu/store/HASH-.../bin/bash
<maximed>/bin/bash doesn't even exist on Guix System
<zeroter>maximed: loadkeys wasn't working on the bash shell spawned with "/bin/bash" (login does it and screen), and worked for simply "bash".
<zeroter>maximed: my system config had (specification->package "bash") included in its packages and "/bin/bash" as my user's shell; but bash and /bin/bash pointed to different locations in /gnu/store
<zeroter>looking at %base-services, it only references "bash"/bin/sh, so that symlink could be from a previous system definition. But shouldn't those links be cleaned when not included in system definition anymore?
<vivien>Hello, does anyone know how the scheme SSAX parser works? Is there an example somewhere on the internet?
<zeroter>I still had dangling symlinks to polkit and dbus (into /etc/static), even after reboot and deleting almost all generations
<podiki[m]>what about services in your system config, would that do that?
<zeroter>nope, the only services are %base-services, hdcp-client, and extra-special-file for putting bash in /bin/bash
<zeroter>and before I added that extra-special-file for bash, I had a dangling bash symlink in /bin/bash from previous system generations
<podiki[m]>hrm, maybe a bug to file? especially helpful if you can give a system configure and then change that reproduces it
<zeroter>I could try. But just to be clear, symlinks created by services (like extra-special-file) should disapppear after reboot if the current system definition no longer has those services?
<jonsger>thats a bit scary. I got yesterday a mail from abuse@hetzner which forwared a mail from BSI (German governmental organisation for IT security) that my server runs mDNS. Today I had a look via Hetzner clouds webconsole: it booted the installer. I have no clue how that could happen. I have no Installer ISO mounted for months...
<podiki[m]>not sure, hopefully someone can answer. I kind of assumed just about anything not in /home was subject to guix cleaning it up
<jonsger>and I don't know how I can but up the installed system from the hard disk...
<jonsger>boot the installed system from hard disk, I mean :)
<roptat>zeroter, it could be that guix doesn't record what it creates in /etc...
<JorgeTern[m]11>Hello, can I open a pack that is not packaged in Guix? for example redmine, org
<yoctocell>sneek: later tell iskarian: re the generic-git updater, I agree a that manually specifying the properties is rather tedious; maybe we could do a regexp match, and if that fails, fallback to the properties?
<yoctocell>sneek: later tell iskarian: and yes, it does need to clone the repo before checking if a new version is available. That's probably overkill; I probably should've use 'git ls-remote' instead. Thanks for taking a look! :-)
<iskarian>yoctocell, do you know if functionality equivalent to ls-remote is available in guile-git?
<sneek>Welcome back iskarian, you have 2 messages!
<sneek>iskarian, yoctocell says: re the generic-git updater, I agree a that manually specifying the properties is rather tedious; maybe we could do a regexp match, and if that fails, fallback to the properties?
<sneek>iskarian, yoctocell says: and yes, it does need to clone the repo before checking if a new version is available. That's probably overkill; I probably should've use 'git ls-remote' instead. Thanks for taking a look! :-)
<iskarian>Also, I think using properties if available, then fallback to a guess would be the way to go
<iskarian>It's conceivable that our guess could be wrong
<roptat>if anything is missing, I would package that first. I think there's an importer too, maybe worth trying
<roptat>(you can't import redmine itself, I tried "guix import gem redmine" but that gives a package whose description is "This package provides a simple REDMINE client, using Active Resource.", so that's not what you want)
<cbaines>jackhill, so, a trivial mirror would just be a caching proxy. That would work, but it would either be slow in answering narinfo requests (because it has to keep asking some origin server), or it would return cached responses that are potentially out of date
<cbaines>I think the way to improve on this is sync up the narinfo data to all of the mirrors, probably by using some database to do that like PostgreSQL
<cbaines>that way all of the mirrors can quickly answer narinfo requests, always responding with the "correct" response