<sneek>ngz, rekado_ says: We do use directories in the origin when it makes sense. The importer produces the shortest common prefix.
<rekado>looking at the tfm files makes this really obvious
<rekado>the good ones from the monolithic package explicitly mention ‘extension’; ours don’t.
<ngz>I had to change locations in at least one package (pgf) because they would provide dir/A and dir/B but the process would fail to install files from dir/
<ngz>rekado: I have put up the following list: <https://paste.debian.net/1230961/>. Checked entries are TeXlive packages that please `files-differ?'. Of course there are more of them, but I only mentioned those I had verified. Would you be interesting in putting it somewhere for coordination?
<paul_j>Does anyone here use dwm here? I have a working installation of dwm on my system, launched via slim and a ~/.xsession file. Over the last few days, I installed stumpwm to have a look at it, and while I see dwm and stumpwm in the options to launch in slim, regardless of my selection dwm would start. Digging deeper, I removed my .xsession file, and then stumpwm is started when selected, but dwm doesn't start - the slim screen goes away,
<paul_j>and then returns as you would see when the window manager is shut down. I find that there is a dwm.desktop file along with the stumpwm.desktop file in /run/current-system/profile/share/xsessions, and this simply launches dwm (and not the compositor etc). I am not sure why this fails - there doesn't seem to be any logging to indicate a problem.
<paul_j>I believe my problem is my understanding of what slim is doing to launch the desktops.
<paul_j>In the documentation, it says "SLiM looks for session types described by .desktop files..." and "It also honors ~/.xsession files". In my .xsession file, the last command is to "exec dwm".
<paul_j>What am I missing? The ~/.xsession file shouldn't be necessary, if my understanding is correct, as the dwm.desktop file should suffice (notwithstanding the lack of compositor, background setting etc).
<paul_j>It isn't clear to me if the ~/.xsession file is run instead of the *.desktop files regardless of which desktop environment is selected by F1.
<son0p>Hi, I'm trying to use doom emacs but modes are not working, there is a GPG error: "no usable configuration", OpenPGP
<son0p>also, when try to open a file another message say Error running hook "global-git-commit-mode" because: (epg-error no usable configuration OpenPGP)
<tschilptschilp23>Say I have a kernel module packaged and installed to my home-config. What would be an appropriate way to make it visible to modprobe? At the moment I have to ~find~ the matching one in ~/gnu/store~ (as it exists for various kernels already) and then ~insmod~ it (after modprobing another one). I'm thinking about sending a patch, as it works nicely, but in this state it's rather unfriendly!
<tschilptschilp23>sorry, that was stupid, for sure it's in ~.guix-home/profile/lib/modules~! So everything fine!
*tschilptschilp23 is seriously wondering about some previous actions
<tschilptschilp23>nckx, roptat: thanks for helping me packaging this thing back then, it still works instantly on kernel 5.15.23! Is there any suggested way for labelling untagged github projects in the package definition? guix lint is complaining about this.
<sughosha>Hi all, again. I am trying to package an app whose link differs according to the architecture. The filename of the tarball differs for x86_64 and arm architectures. In Arch Linux, I was able to do like `source_x86_64` and `sha256sums_x86_64`. I would like to know if there is such a way in Guix. Thank you for any help!
<efraim>sughosha: firstname.lastname@example.org has two different input tarballs, one for x86_64 and one for i686
<efraim>although normally this is a case of pre-compiled software, which is almost always not accepted into Guix
<sughosha>efraim: Thank you! So I have to make them as different dependencies.This helped me a lot.
<efraim>happy to help. It certainly is useful when the sources already have something to point to :)
<alextee[m]>rekado: is that stilll relevant? should probably use pipewire these days
<sughosha>Also I'm aware of Guix's policies, and that's really great thing about being strict. I'm just packaging only for myself locally, as I was unable to compile one software from source. I never send such patches to Guix.
<civodul>sughosha: you don't need to justify yourself :-)
<vivien>sughosha, be careful, if you don’t recompile your package it might break badly
<vivien>You need to patch things, I don’t remember exactly what and how
<efraim>civodul: regarding linting language libraries, there was a CVE against lru<0.7.1. Artifically lowering rust-lru to 0.7.0 and changing cpe-name to "lru" made it appear, so i'll add 'rust-' to the prefixes to strip
<sughosha>vivien: Yes you are right. I am able to run it temporarily with `patchelf`.
<sughosha>I cannot run it without packaging and installing, because every .so file, and their dependencies too, need to be patched correctly. And that's really a great thing I like in Guix :)
<rekado>reading the documentation of amsfonts I’ve come to the conclusion that we shouldn’t try to build the tfm files.
<rekado>they are part of the bundle and are not expected to be built by converting the afm files
<qboltz>Is there a standard setup to use tlp on guix? Not getting much on google. Seems the default config file isn't being placed where it's expected upon install in /etc or /etc/default. Should I just make one in either of those locations, or is there another solution?
<nckx>tschilptschilp23: Hi, sorry, I've been AFK since. If your question is still open: what do you mean by ‘labelling untagged github projects’?
<dongcarl>janneke: Hi, long time no talk! Wondering why you added --with-newlib to the gcc options for mingw-w64 targets? It's breaking something for me and I'm not seeing it in debian build rules and Fedora explicitly does --without-newlib
<minikN>Hello. Until a couple of weeks ago I was able to view build logs using bzcat /path/to/log. But that isn't working anymore, it's telling me know that ...drv.gz is not a bzip2 file. Did that change?
<anticomputer>so I spent the weekend having a bake-off between guix and nixos, building both to my workstation spec, and I'm happy to announce that guix is about to be the daily driver because after the nixos setup, building the exact same setup in scheme felt like a carefree stroll in the park, the ability to bootstrap a custom channel for my personal crud in ~10minutes was also <3
<anticomputer>very intuitive and hackable, 10/10, would reconfigure again
<tschilptschilp23>nckx: It's a warning in connection to git-fetch I use there. I've beautified it up a little already according to guix lint, but I could not get rid of a warning, that the source does have no tags, or similar. This is cited out of memory, I will be back on that as soon I reproduced on a git-checkout! this is the package: https://paste.debian.net/1231004
<zimoun>civodul: is it expected that “--help-transform” does not display --tune? Or just soemthing that have fallen in the crack?
<civodul>apteryx: i don't think i can fix local-file today but at least i have a lead: gexp seems to lose source location info for things that appear in (ungexp ...)
<civodul>the workaround is to write (define lf (local-file ...)) and then: #~(... #$lf ..)
<zimoun>yeah, but when I am at the CLI, if I have to open the Guix manual, go to tune, follow, piouf! Even if info and index are nice. mothacehe proposed somehow to have a list, maybe it would help to ease, no?
<nckx>tschilptschilp23: I got the warning now. You can ignore it.
<nckx>It's just stating a fact about the upstream repo that we can't change.
<tschilptschilp23>nckx: cool, thank you! Yes, it seems to me that it was exactly about that one! Sorry for being slow, I'm still somewhat struggling with placing stuff in guix...
<nckx>Alternatively, if you care, you could ask upstream to create tags, but even if they do so on request I'm not optimistic that they'll remember next time, making its value as an update signal moot.
<tanner40>I had thought that `xorg-configuration` evaluated to a matching instance
<civodul>rekado: right, that makes sense; nothing's actually grafted, but what matters is that users get the correct variant
<nckx>tanner40: Only if you defined your own xorg-configuration previously. There's no ‘default’ xorg-configuration variable, or rather, omitting the (inherit …) entirely will already use all the defaults.
<tanner40>nckx: thanks. it seems like right way to do what I want is `set-xorg-configuration`, I'll give it another try
<apteryx>rekado: hey, sorry, missed your last messages; are you still around the MDC? otherwise we can try tomorrow, there's no rush
<lfam>I know we have `guix size` and `guix processes`. Are there any other tools for profiling Guix? Specifically, for measuring resource consumption at run-time?
<janneke>dongcarl: i don't remember, i added --with-newlib probably because i used that before in mingw cross-builds (and it worked here)
<janneke>it was my understanding that you need --with-newlib whenever the libc is not glibc
<apteryx>lfam: if it's a user-side process (not doing its work through the daemon), you could use the 'time' command (not the bash builtin)
<apteryx>it will print how much memory was used by the command
<lfam>Interesting, I didn't that it could do that, although I must use the builtin normally
<rekado>you can try rebooting in between if you’re feeling lucky :)
<PotentialUser-49>Hello! Before I type too much, is this a good place to ask a question about packaging? I'm trying to learn it for learnings sake (i.e. try to modify the build phases, have it fail and figure out how to fix it), rather than the specific outcome.
<dongcarl>janneke: Okay I see! Unfortunately --with-newlib actually prevents libstdc++ configure from knowing to use _wfopen from mingw-w64, causing all kinds of chaos with the std::filesystem classes. Things are working without the flag and other distros don't specify it (or in the case of Fedora, explicitly --without-newlib) so I think it might be safe to
<janneke>iwbn to get wip-mingw merged in guile, but that probably needs some work
<PotentialUser-49>ngz Thanks. I'm attempting to add a step to the package for nim. I am at the stage where it's failing because it looks to me like nim is executing gcc via the shell. From what I can tell, all strings "/bin/sh" are fixed up using substitute*. What I'd really like to be able to do is replicate the exact environment in which I see the error.
<PotentialUser-49>I'm stupidly injecting things in order to debug my problem. However, guix environment and guix shell set things up so that the failure doesn't occur.
<PotentialUser-49>What's the correct way to get in and work in the exact same environment as the build?
<stikonas>lilyp: I think it's vendored in rustc tarball as dependency (and source is there too, so can be rebuilt), but let me check
<ngz>PotentialUser-49: guix shell --pure -D nim should provide you the same environment
*janneke goes for a git clean -fdx (after having done a make clean-go all :-(
<PotentialUser-49>ngz That's what I've tried, but that doesn't seem to get me into the same situation. In order to experiment, I recreated my package definition in a scheme file. so I do guix shell --pure -D -f nim.scm. On in the enviornment, I untar, run the same fixups using substitute* and things build ok. I believe it's because "/bin/sh" still exists in
<mcd>hi, I installed guix with an encrypted /. Now I have to insert the disk password twice before I get to the login screen. I used the guided install. I think, the manual/installer should warn about that.
<mcd>And why is that, anyway? Is this issue tracked somewhere?
<rekado>(I was actually just out to do some wood working… so I’m glad nothing bad happened while I was away.)
<djeis>So I'm trying to use the grub-efi-netboot bootloader, and I've got it all the way past grub and in to the initramfs but when it tries to mount my root over nfs I just get "Network is unreachable". However, I don't see a good way to configure the network settings in the initramfs. Is there something I'm missing? I sortof figured the network card would maintain the dhcp settings it used to PXE boot.