<pkill9>i have an idea: chromium/icecat extension that tells you if you are looking at a piece of software and it's been packaged in guix, e.g. when you are looking at it's source URL, or on it's homepage
<apteryx>hmm, my vm in gnome-boxes keeps loosing network access... I wonder why.
<xelxebar>Anyone here successfully using xinit with a guix system?
<xelxebar>Starting xinit fails and populates the Xorg.0.log with "systemd-logind: failed to get session: The name org.freedesktop.login1 was not provided by any .service files"
<xelxebar>It looks like elogind provides the file share/dbus-1/system-services/org.freedesktop.login1.service
<xelxebar>Not sure if related, but my "term-auto" service looks to be stopped.
<xelxebar>Ugh. Nevermind... I forgot to install xterm :/
<xelxebar>Oh, and then there's the xorg-startx-command service...
<raghavgururajan>After doing `guix time-machine --commit=f43287aff06082c83649a1d0c0184b9ac347c3c8 -- system reconfigure /etc/secondary.scm --allow-downgrades`, system was working fine. So I GC'd everything.
<raghavgururajan>But now I cannot even do anything without building everything like gcc bash etc..
<raghavgururajan>This started appearing: substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable
<raghavgururajan>At this point, I am unable to do `guix pull` or `guix system reconfigure`.
<mroh>maybe you have a /etc/guix/acl.bak file that you can copy to /etc/guix/acl
<raghavgururajan>For information, in current state, `guix describe` for user and root gives, 582cf9257cd1f9c969fbba5eb1c336ac8b975cde. Though current system generation is based on f43287aff06082c83649a1d0c0184b9ac347c3c8.
<lfam>I know the way that file is handled changed recently but I didn't pay attention to the discussion
<raghavgururajan>lfam: I never had to manually deal with acl file. Would using time-machine for system reconfigure could have caused something to change?
<xelxebar>raghavgururajan: Have you manually run `guix archive --authorize` before?
<lfam>Since I don't know the details of what changed, I don't have a precise idea, but I'd guess that going back in time (--allow-downgrades) could have some unexpected effect if you went back to before the changes
<lfam>On Guix System, you shouldn't need to do anything about that file xelxebar
<lfam>What does that file contain on your system, raghavgururajan?
<xelxebar>raghavgururajan: That command sets up your /etc/guix/acl file, but guix expects you to configure your substitute server auths via an operating-system config, so when you reconfigure, it clobbers /etc/guix/acl. As mroh mentioned, if you *did* manually add servers, then your old /etc/guix/acl gets moved to /etc/guix/acl.bak.
<xelxebar>lfam: Thanks. I found bayfront.guix.gnu.org. Is it substituting for any particular class of packages? Just curious why it exists.
<lfam>The short version of the story is that we wanted to use it to create the "new" build farm, but ended up with the build farm hosted at berlin.guix.gnu.org instead. Previously, Guix was hosted on a VM by the FSF, but we outgrew it
<lfam>I mean, Guix something that can be "hosted". Our build farm was hosted at FSF
<civodul>it seems unlikely that running "guix pull" in the container would break things outside
<ngz>civodul: I answered yesterday to #43910 (#43911 is the same). I am waiting for an agreement (should I ?).
<davidl>civodul: running the guix command outside the container doesn't work anymore and restarting the guix-daemon with systemctl restart guix-daemon fails etc. I actually couldn't even login to my user afterwards. Fortunately I had a recent snapshot of that VM so I just restored.
<civodul>ngz: oh right, sorry; well maybe you can go ahead, it's been a while already
<davidl>civodul: no program from /gnu/store outside the container would start. not sure if guix pull from inside the container operates on the the same /gnu/store or not. The container was created with guix system container simpleOS.scm --network and then started with sudo /gnu/store/xxxx-run-container
<davidl>civodul: it happened twice by the way so probably reproducible.
<civodul>davidl: can you copy/paste the commands and output so we see what you mean by "doesn't work anymore" etc.?
<davidl>I can, but it is going to take a while before I get around to it.
<Fenlair>Hey everyone! I would like to package remmina (open source remote desktop tool, I believe from the same repo as freerdp?) Do you think that would be a good candidate for a first package? The dependancies look a bit daunting, but on the upside there is already a nix package of it.
<civodul>hi Fenlair! as long as it uses a standard build system (Autotools, CMake, Meson, etc.), it should be fine
<nckx>Winux: I'm assuming you mean GDM's session list and qtile is a wm (I'm assuming a lot). Does qtile provide a .desktop file in the expected place in the output?
<civodul><nckx> Winux: I'm assuming you mean GDM's session list and qtile is a wm (I'm
<civodul> assuming a lot). Does qtile provide a .desktop file in the expected
<nckx>Fenlair: Also, questions are always welcome here, even ‘this doesn't work <pastbin of you code>, halp’.
<OriansJ>very stupid idea but: guix builds should be slower. Here is the idea: all builds should be done on a qemu virtual machine with as minimal specs as possible (per build) and get away from the bad idea that the package definition should be in the scope of the hash; which would allow one to build, document the final hash as well (to check the binary) in the package definition.
<OriansJ>Thus making all builds host/cpu/etc agnostic
<Fenlair>One thing that I try to wrap my head around. We use a module system on CentOS to get certain packages with certain dependancies loaded. But sometimes this goes boom, if you load two modules that use two different versions of, let's say Perl. How would that work on Guix, if I have Perl in the (install ...) list, it will not show up in my PATH and it wouldn't mess with anything else, but how does that package then know itself, which Perl
<Fenlair>nckx: in the package definition, there is (native-install ...) and (install ...) and I think (propagated-inputs ...), the last one being propagated to the PATH (if I understood that right). So propably if Perl is dynamically linked it would have to be in the last list?
<Fenlair>oh it's always inputs not install, sorry about that.
<civodul>nckx: i don't think there's a helper to create .desktop files
<nckx>Fenlair: The ‘perl’ in your *inputs will be a "/gnu/store/<hash>-perl-<version>" string at build time. So ‘which perl’ will return /gnu/store/<hash>-perl-<version>/bin/perl. It's expected that your package embeds that absolute reference in all generated binaries/scripts. That usually Just Happens™, but if a the software does something like ‘execlp("perl" ...)’ at run time it should be patched to use absolute file names.
<roptat>(guix build utils) has make-desktop-entry-file
<Fenlair>nckx: no worries, I'm already very thankful for that answer! Also OriansJ. The concepts haven't quite sunken in yet. What confuses me now is, that which perl would point to something in inputs. Isn't the difference between input and propagated-input, that in input the binary isn't put into the profile? And if it isn't in the profile, I would have expected it to not show up in the path/which.
<zimoun>I am proposing to shift a bit the deadline
<roptat>Yeah... 6th to 14th was already short, but here you're giving 4 days to record :/
<roptat>I don't think you really can create a presentation and record it in just 4 days
<nckx>Fenlair: The ‘which perl’ I'm talking about is at *build* time, i.e. if your configure script or Makefile run ‘which perl’. perl is in $PATH in the isolated temporary build environment. However, if a user installs swaks (a Perl script) into their otherwise empty profile, the user running ‘which perl’ won't return anything because perl isn't propagated. How does swaks find its perl? It hard-codes the /gnu/store/.../bin/perl file name, so
<nckx> perl never needs to be in $PATH after the build.
<nckx>swaks' shebang is #!/gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/bin/perl.
<nckx>and it's launched through a wrapper script that sets up $PERL5LIB.
<nckx>Ideally it should ignore whatever $PATH and $PERL5LIB you have in your filthy environment.
<Fenlair>if I do 'which perl' on the command-line, it has to be on the $PATH, no?
<xelxebar>Hrm. Even getting the udev rule setup, I'm still unable to access the yubikey :/
<nckx>Hm, if I let the Makefile do its thing (running objcopy --strip-debug --strip-unneeded) it produces a 6.7M .so with 7.7M .so.debug. But I want Guix to handle it, so I patch it out, but Guix creates a 7.7M .so and 99M .so.debug.
<nckx>I'm not even sure what my question is but: why?
<nckx>I'd like to get the .so down to 6.7M at least.
<nckx>Fenlair: C... clear? I'm always surprised but happy to hear that. (‘Regular Linux environment modules’ don't ring a bell either, I'm afraid.)
<Fenlair>nckx: I'm not saying I understood all of it ;) But it's a lot less foggy now :D It's just a tool to help change environment variables dynamically. You can do 'module load gcc/8.3', which will setup your path to point to the right binary and then 'module switch gcc gcc/9.2' and it will change your path. I assume most of that is just not needed anymore with Guix.
<zimoun>nckx: Sorry for the annoyance. It was to test if the alias really works. It does. :-)
<nckx>Fenlair: Sounds like Debian's ‘alternatives’ system, which which I'm also not very familiar but have at least heard of. Does it change your $PATH (similar to guix environment) or the actual presence or location of symlinks (similar to guix install)?
<nckx>But yes, Guix replaces such systems with its own.
<Fenlair>nckx: It is quite flexible, if I remember right the module scripts are written in TCL, usually you just change the environment variables like $PATH.
<abcdw>civodul: thank you, inferiors is a nice tool, but it's a little pitty, that channel doesn't bring his own dependencies with himself.
<abcdw>civodul: I found flake mechanism in nix pretty interesting. It is similar to channels, but from flake defenition flake.lock file generated, which contains not only this flake dependencies, but also transitive dependencies. It allows to have to separate nixpkgs versions at the same time for single environment without additional work. Probably it's not possible with guile, because it will result to name collision.
<roptat>nckx, yes according to the Last-Translator header
<abcdw>Yep, I checked "guix describe", it works pretty well for locking, but I don't see a way to pull transient dependencies automatically. For example: channelA uses channelB and my code uses channelA, if I specify channelA in channels.scm guix pull or time-machine won't pull channelB as I understand.
<civodul>abcdw: duplicates are removed and the most specific one wins
<civodul>so if there's one with (commit "xyz") and one with (branch "master"), the former wins
<abcdw>civodul: got it, thank you for explanation)
<civodul>zimoun: did you start working on NEWS & the release notes?
<civodul>if not i can maybe take a look later today
<zimoun>civodul: or talk about about Jupyter which is ready. :-) Or talk about guix-past and paper to code. Or about the experience in INRIA Bordeaux. Or a rough draft about the maybe FOSDEM talk. Or your opiniotated ROADMAP.
<leoprikler>vits-test: `tree` exists. There are subtle differences between how everything is nicely displayed and how stuff works under the hood as well
<apteryx>The mechanism relies on inotify (on $HOME/.guix-profile/share/applications, in our case), so perhaps if the parent directory is switched via symlink it could fail detecting any change (just an idea)
<leoprikler>If you're writing a typical web application frontend you don't care too much about the node in the backend, do you?
<roptat>abcdw, I'm a bit ahead, but guix also supports the Hurd now :)
<OriansJ>vits-test: I am very serious but for exactly the reasons you specified. I want to know for absolute certain after x hours of building that it will always succeed.
<OriansJ>right now I do a guix pull and it might not even successfully complete and figuring out why is not exactly easy.
<OriansJ>right now I managed to find a way to get /gnu/store/qm3l79ic89qpjjd8avqxd81425v4wvv5-gnutls-3.6.A.drv to both successfully complete and fail when being built from identical (minus the CPU cores) systems.
<OriansJ>and I have no idea where to even start figuring out the reasons for that.
<OriansJ>as they have identicial binaries at the start; both are 36GB of ram with matching SSDs; everything identicial as I can manage but somehow; 8 cores fails but 2 cores are successful. (doing a diff on hardware not possible) but the starting file systems are bit for bit identical; yet different results
<apteryx>OriansJ: is it failing in the test suite?
<apteryx>i'd bet if you ran it with #:parallel-tests? #f (or -c 1) it'd always succeed.
<OriansJ>vits-test: well it is true; compiler optimizations can easily generate non-functional binaries but that is why we have generic targets like i586; which all later x86 processors can successfully run.
<OriansJ>but then again my goal wasn't the fastest binaries possible but rather binaries that work successfully on as many systems as possible and can be built identicially on as many systems as that exist.
<roptat>abcdw, a stable branch would mean you keep the old guix utilities too
<OriansJ>roptat: that is what people get when they grab the latest guix binary now anyways.
<apteryx>I can see that's not convenient, but it should technically work.
<OriansJ>apteryx: because the nar file format changed between 1.1.0 and now
<OriansJ>I am not certain when but if you install a guix 1.1.0 binary and do guix archive --import using the example nar in the documentation. It straight up complains that it isn't a valid nix file
<OriansJ>and when one installs a frest 1.1.0 binary and trys to do guix archive --export to generate the binary; it produces something that by default it also considers corrupt; eg guix archive --export bash | guix archive -t (will fail)
<apteryx>OriansJ: that seems an unrelated issue, I could reproduce it on a current Guix yesterday
<OriansJ>now there might be a procedure to make that work (I just don't know what it is)
<OriansJ>apteryx: yes but the point is if the nar files one can get from ci.guix.org are not valid to import and one can't build nar files that it'll consider valid and one is not able to build the file locally; one is stuck
<Fenlair>I started packaging remmina. guix package -f remmina.scm returns with 'guix package: error: cannot install non-package object: #<unspecified>'. My remmina.scm is -> https://pastebin.com/SR8ZxCYh. Any idea? :D
<zimoun>maav: yep, I am favor to branch today. :-)
<abcdw>roptat: You are welcome!) Thank you for joining and participating!
<apteryx>sneek later tell civodul I've tried inotifywait on $HOME/.guix-profile and $HOME/.guix-profile/share/applications and it indeeds fails to report any change when the guix-profile symlink gets switched.
<Fenlair>vits-test: Thanks, adding remmina to the end worked, now I get some real errors :P
<vits-test>Fenlair: modules shouldn't evaluate to anything
<vits-test>Fenlair: with remmina at the end, evaluation will happen every time someone or something loads this module.
<Fenlair>vits-test: Ah remmina.scm is a module, so I should add it's directory to the module search path and make it install normally?
<kozo[m]>Hello all, I'm working on making a guix iso for raspberry pi's. I installed guix binary and am looking at the disk image option. However, I need a config file to pass to it. Does the binary put a .scm file somewhere that I can use?
<vits-test>Fenlair: better someone smarter will answer, but basically the process is described in manual. To package something for everyone, U better to work from our git tree.
<vits-test>Fenlair: basically, if U drop remmina.scm to gnu/packages in git tree, U can `./pre-inst-env guix COMMAND remmina`
<vits-test>Fenlair: (after `guix environment --pure guix`, then `./bootstrap && ./configure --localstatedir=/var && make -j`nproc`` in git tree, again)
<maav>zimoun: cool, i'm working on some extra translations too, as i've already have the manual and guix upto master, hehehe
<maav>i hope i can send a patch for the web soon...
<Fenlair>vits-test: Thanks for the info! I will have to read the manual, since the last step went right over my head :D But it would be cool, if I could commit the package once it is running (and I feel a bit more confident in my Guix abilities :P)
<vits-test>kozo[m]: I'm not sure if we have U-boot (bootloader) for Raspberry boards.
<dustyweb>samplet: well my spouse just started running guix on her machine (she did the install on her own! I just stood by and explained a few things)
<dustyweb>we have everything she needs except the assistant, so I'm going to try to get that enabled I suppose
<dustyweb>we went through enough of a long time where "this isn't a good time for me to upgrade my debian machine in case things break" and that accruing that we were like, "you know what, we need to break that cycle". And Guix is generally usable enough these days :)
<vits-test>Fenlair: i pressed the "raw" button, and now see no that too. Maybe some emacs-w3m bug..
<samplet>dustyweb: Cool! I don’t see a patch, so maybe I’m mistaken. We have way more Haskell Web stuff since then, so hopefully it will be easy.
<dustyweb>samplet: could you explain what that means, the versions from there...?
<zimoun>dustyweb: git-annex-assistant was my initial goal when I hitted http://issues.guix.gnu.org/43843 then I was too exhausted to finish. ;-) Note that for reproducibility, the parallels build are truned off by default, so I can take a while when you build locally.
<dustyweb>zimoun: did you find out anything about what was "needed" in the process? :)
<zimoun>I do not remember. But as samplet said, the Haskell situation is not so bad now and the importer works more or less.
<zimoun>Haskell LTS is a collection of Haskell packages that are known to work together. Well, it is an Haskell distribution somehow.
<samplet>dustyweb: All of our Haskell packages have to work together. The Stackage people maintain a list of package versions that work for certain GHC releases. The “LTS 14.27” list matches our current GHC.
<samplet>If we stick to their list, we can avoid “dependency hell”.
<sneek>civodul, apteryx says: I've asked in #gnome, and apparently GNOME Shell is supposed to detect changed .desktop entries automatically.
<sneek>civodul, apteryx says: I've tried inotifywait on $HOME/.guix-profile and $HOME/.guix-profile/share/applications and it indeeds fails to report any change when the guix-profile symlink gets switched.
<sneek>civodul, zimoun says: do we branch v1.2 today?
<cbaines>civodul, going back to when I was talking about Guile+SQLite segfaulting, after lots of not getting anywhere, it's just occurred to me that it could be just like the PostgreSQL bindings, and be another GC race condition https://paste.debian.net/plain/1169833
<apteryx>its first monitor argument is a pointer to a GFileMonitor object, which implements the inotify stuff
<zimoun>civodul: did you do something about NEWS today?
<lfam>Fenlair: If the software doesn't have a test suite, you can add '#:tests? #f' in the arguments of the package definition
<apteryx>civodul: interestingly there seems to be a polling based mechanism available (gpio/gpollfilemonitor.c), perhaps we can configure glib to use this instead of the gio/inotify/ginotifyfilemonitor.c for its GFileMonitor detection mechanism.
<vits-test>ss2: the thing U commented out, with (string-append "QMAKE_LRELEASE=" lrelease), seem to be "righter"
<vits-test>ss2: though there should be some #:configure-arguments or alike, rather than replace the 'configure phase
<ss2>According to the source README, I'm supposed to do a qmake && make && make install. There's no configuring. But then my knowledge about qmake is limited. Especially how to string it into quile code. :)
<Fenlair>In a package definition, in the arguments field I have a quasi-quoted list. If I want to reference to a package path in the configure options, do I have to unquote the package name? Something like this (arguments `(#:configure-flags (list (string-append "-DFREERDP_LIBRARY=" freerdp "/lib/libfreerdp2.so"))))
<vits-test>ss2: in guix git tree: git grep qmake. Shows lots of invoke "qmake", seems U done right.
<ss2>I've been reading around seeing how others have done it.
<vits-test>ss2: seen gnu/packages/telephony.scm? it has lrelease
<vits-test>ss2: maybe order should be `qmake that-file.pro VARS`?
<ss2>yes, just tried that snippet. At least the error code changes from 3 to 2.
<nckx>Well, it's not illogical to want something as simple as quoting/unquoting instead of this, and IIRC that's exactly what the ‘gexp-based build system’ could provide, but it hasn't been merged.
<ss2>vits-test: that didn't work either, but thanks for your help anyway, I'll have a look at it another day, and I didn't expect that it would be that problematic to compile it.
<vits-test>ss2: Maybe lrelease is in another package, then. But another day is another day.
<nckx>ss2: I haven't read the entire backlog. Any reason for not using the qt-build-system?
<ss2>it doesn't work either, and fails with the same error message: the lrelease executable is not found.
<ss2>I tried it with gnu, qt and cmake, they all fail.
<nckx>ss2: https://paste.debian.net/plain/1169847 - Tries to install to /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/qt5/plugins/platformthemes/libqt5ct.so, so you still need to do harder $prefix convincing, but it builds.
<OriansJ>apteryx: only if one wants to be exact when providing the steps so that others can replicate your findings exactly
<cbaines>civodul, no luck with SQLite debugging symbols, I've tried pretty much everything I can think of, but gdb still says there are no symbols available. I just sat down to write a reproducer though, I'm pretty confident it'll be easy to reproduce.
<OriansJ>odd guix is downloading the binaries that were already built locally
<OriansJ>does guix not actually check for locally built binaries when substitutes are authroized?
<cbaines>OriansJ, do you mean locally build store items, rather than binaries?
<cbaines>If these are indeed store items, I wonder if there's some issue with the daemon's database, either it's got out of sync with things actually in /gnu/store or it thinks some are invalid
<OriansJ>cbaines: as in the binaries which were built by guix from source code in the process of guix pull and guix build
<lfam>Considering your recent message about the signing key, I wonder if something is wrong on that end?
<apteryx>OriansJ: also note that there's an installation script for Guix available that would have probably helped avoiding the gotchas you seem to have run into
<lispmacs[work]>I want to generate a channel specification file for the previous generation of my profile. Is there a way to do that?
<OriansJ>looking at gnu/service/base.scm; specifically %default-authorized-guix-keys; it appears that only keys labeled '/share/guix/berlin.guix.gnu.org.pub' as the record authorized-keys appears not to be used to add additional keys anywhere.