IRC channel logs
back to list of logs
***lukedashjr is now known as luke-jr
<pkal>When using guix import, is there some better way to find the imports than looking each up manually? <pinoaffe>pkal: do you mean finding out which modules you need to load? <pinoaffe>I personally always just run `guix package -A <input-name>` in a shell for each input <pkal>pinoaffe: Yes, I was wondering if there was some guix script that could do that for you (take a script with missing inputs, and output all packages it could find) <vier-littleme>how does the cuirass work? does it need a worker? i wana setup a cuirass service for develop.
***m5zs7k_ is now known as m5zs7k
<efraim>rekado: nhc98 almost worked on powerpc-linux, I got some segfaults in MkConfig <efraim>still no luck on armhf-linux and gcc-2.95. probably an alignment issue and armv5 vs armv8 <civodul>so! i still fail to get a bootable system with recent commits <civodul>now entering hardcore debugging mode <civodul>if anyone else has clues, i'm all ears! <civodul>i wonder if it's the childhurd service somehow breaking things <tschilptschilp23>6bfb3fc1f450c7d618041303d0ff35691b5991c0 works here. But I'm not using the childhurd service <vldn>41000d16c5c1586482a76d856c3152a6b8fcce8a is running here, but i'm on a github mirror <civodul>for 2022 it's going to be mostly FOSDEM <civodul>sneek: later tell mothacehe hi! your talk videos are missing from fosdem.org, perhaps you need to approve them or something? *rekado is still building the aarch64 system to upgrade the honeycomb machines… <rekado>found something bad: the texlive ‘Insufficient extension fonts’ message is likely due to the fact that we’re building fonts from source. <rekado>all the complication of running mf and afm2tfm … just leads to bad fonts <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? <rekado>could you send it to firstname.lastname@example.org? <rekado>the biggest problem I have with TeX Live is that it’s so hard to tell what needs to be built from source and what is supposed to be accepted as a raw input <rekado>does anyone ever build these font files from the other formats? <rekado>or have they been built once and now are just passed down as blessed binaries? <rekado>have they been modified with some interactive software? <rekado>it’s so hard to tell, and there are no instructions <rekado>we could *easily* do what everybody else seems to be doing: take the big texlive tree, chop it up as we please, and deliver the chunks as packages, done! <vldn>someone succeeded in running waydroid on guix? <jonsger>rekado: I'm happy if I find the guix packages required for my TeX stuff, I didn't started packaging yet. Although I have some stuff which would be nice to have packaged... <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. <civodul>if anyone has similar problems, let's join forces <efraim>civodul: 5.15.22 failed to boot for me and I got a backtrace, 5.15.19 works for me <efraim>5.15.19 is self compiled, 5.15.22 is a substitute <civodul>efraim: ah, that sounds like yet another issue <jpoiret>there has been at least one other person with kernel issues <efraim>yeah, I was going to see about replacing 5.15.22 with one I built but haven't gotten around to it <efraim>might just try reconfiguring on master and building 5.15.23 myself <efraim>there's always someone with kernel issues though, so I didn't say anything <efraim>civodul: I almost got ghc@4 building on powerpc-linux <efraim>and I should probably talk to danny about armv4 or armv5 and email@example.com <civodul>for me kernel issues are extremely rare <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! *jonsger is already on 5.16 :) <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? <qboltz>guix system not a foreign distro <apteryx>attempting to reconfigure berlin, I get: guix system: error: canonicalize-path: No such file or directory: "../../sync-disarchive-db.scm" <apteryx>rekado: let me know when it is a good time to reboot the berlin <rekado>apteryx: now would be fine, I guess <rekado>I’m connecting to the serial console… <rekado>you’re now the only one logged in <rekado>64fcf9508af318cc2d71811815cfbe99063867b1 should fix the ‘Insufficient extension fonts’ problem <rekado>maybe it even fixes the komascript problem…? <rekado>too bad. Bug #33094 still exists. <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? <minikN>I see, but it was a bzip file before, wasn't it? <rekado>depends on the --log-compression=TYPE option to the daemon <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? <sneek>zimoun, rekado says: The first hint for 40558 is that stmaryrd doesn’t contain any font files… <tschilptschilp23>(and it's correct, the repo has no releases or tags, it's just a repo with nicely working code of a person I do not know personally) <civodul>zimoun: hi! sounds like an omission! <zimoun>ok, and --list-cpu or similar is missing, no? well, I have to open the source to know what is acceptable by the option. <zimoun>rekado: thanks for the fix about fonts. I am trying… <nckx>tschilptschilp23: Thanks. So ‘guix lint’ is what prints a warning? *nckx wishes it supported -f … <civodul>zimoun: it's the source of GCC you'd want to open, but the Guix manual links to the fine section there :-) <civodul>most of the time you'll just want --tune <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. <nckx>tschilptschilp23: No problem whatsoever. <civodul>zimoun: but like i wrote, --tune is usually enough, no? <rekado>I still have a couple of grafts for texlive packages. Is this fine to push replacements to the master branch? Do I need to ungraft them on another branch right away? <nckx>Also: proper hullo again, Guix. It's been a while… :-/ <rekado>(the packages themselves have aleardy been pushed, just not the (replacement …) field) <civodul>rekado: i'm wondering, does it make sense to graft texlive packages? they're only used at build time, right? <zimoun>civodul: no --tune is not enough; for instance it incorrectly recognize my CPU. See recent discussions about openblas. <civodul>zimoun: even with efraim's latest changes? <civodul>now, if you know it guessed it wrong, you probably know what the right value is :-) <zimoun>the right value is not supported by GCC, if I read correctly the GCC section. :-) <zimoun>well, I have not tried yet the last change by efraim. But it does not change that displaying this list of supported CPUs appears to me worth. I do not know. <zimoun>rekado: thanks! New tex works! \o/ <tanner40>where is the guix source located on Guix System? can't seem to figure it out :( <drakonis>if you use guix edit <package>, it'll open a package definition with an editor and depending on the editor, you'll have a visible path to the current copy of the repository <rekado>tanner40: can you show actual code? <rekado>civodul: I thought it makes sense; it replaces the broken package with a fixed package when asking for the broken one. <rekado>so users who install texlive-* packages get the good stuff <rekado>packages that use texlive-* inputs are unaffected <tanner40>(service (slim-service-type (slim-configuration (xorg-configuration (inherit xorg-configuration) (extra-config '("xrandr ...")))))) <jpoiret>tanner40: (inherit ...) takes another instance of the record type <jpoiret>do you have a more complete snippet? (that you could post to paste.debian.net) <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 <jab>Looks like I need to update my certs for gnucode.me <faust>how i can install custom xkb layout in guix? <jab>faust...maybe...I guess I don't really know haha. <apteryx>lfam: I'm sure there are other ways, but I have this Bash alias to let me use 'time': alias time+='$HOME/.guix-profile/bin/time' <faust>maybe any one knows? how to install custom xkb layout in guix? in debian i need to put xkb file under /usr/share/X11/xkb/symbols/ <apteryx>lfam: command time -f"cpu: %P, mem: %M KiB, elapsed: %E, sys: %S, usr: %U" sleep 0.1 <lfam>And I realized that I don't know how to profile Guix, to even begin to understand why it needs a certain amount of space to work <lfam>Like, how would I analyze why `guix pull` needs >1GB RAM <apteryx>in a nut shell, guile compiling modules, so you'd have to dig why guile requires such amount of resource <apteryx>but I'm equally curious to know what means exist to allow profiling guix/guile <lfam>Yeah, I have an intuitive understand of what's going on, but it feels unsatisfying to tell bug reporters "the codebase is large and must be compiled" <rekado>apteryx: I’m not at the MDC, but I have a serial console open <rekado>I’m about to be offline again (bed time for the little one, which means lots of stories), but if something’s wrong I could look at the serial console and press the any key. <rekado>gotta go now, but will be around later <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>dongcarl: ouch, well as long as things as guile will still cross-build; go for it! <dongcarl>janneke: Oh, is the right way to test: ./pre-inst-env guix build --max-jobs=(nproc) --target=x86_64-w64-mingw32 guile ? <janneke>dongcarl: oh crap, i forgot...if only it were so easy! <janneke>it should be...but guile-3.0 needs patches <janneke>there's a wip-mingw branch in the guile repository that has a recipe; GUIX_PACKAGE_PATH=guix guix build --target=x86_64-w64-mingw32 guile-mingw <janneke>do you have a branch / patch without the --with-newlib for me to test? <apteryx>rekado: OK, thanks, and happy reading :-) <janneke>dongcarl: or is it simply commenting-out the --with-newlib? <janneke>hmm, that's more difficult, cross-newlib? and such <stikonas>rust bootstrap chain might be using some pre-built binaries <stikonas>though that issue might go away if somebody bumps mrustc to build rustc 1.54 rather than rustc 1.39 <lilyp>The issue never goes away until Rust has a sane bootstrap history :) <lilyp>We're just moving the goal posts with mrustc trying to keep up with upstream <stikonas>lilyp: true, but that issue was adding some additional blobs even when mrustc is used <ngz>PotentialUser-49: Yes, this is the right place. <lilyp>Is VTE part of the rust bootstrap chain? <dongcarl>janneke: Thanks! I want to make sure such a change won't break anything your side :-) <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 <apteryx>unless it's one of the bundled dependencies <janneke>on latest master: ./pre-inst-env guix build *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
***PotentialUser-49 is now known as mrw
<rekado>apteryx: okay, how about rebooting now? <ngz>mrw: True, there's /bin/sh in the shell. <mbakke>ngz: I'm getting a test failure in 'fish', did it build for you? <ngz>mbakke: Yes it did, as reported when I closed the report. <ngz>When does the test failure happen? <ngz>mrw: Another option is to add the "-K" flag to "guix build", so you can inspect source code and see if there are suspicious calls to GCC there. <ngz>mbakke: I get this: "/gnu/store/5klzwzgdk75yxwpmnq7w0fl0aw21pbh4-fish-3.3.1" <mbakke>mrw: you can add --container for a completely isolated environment, and simply delete the /bin/sh in the container <mbakke>ngz: make: *** [CMakeFiles/serial_test_fishscript.dir/build.make:73: CMakeFiles/serial_test_fishscript] Error 1 <ngz>mbakke: Could it be related to parallel tests? <mrw>mbakke ngz Thanks, I'll look into both. I'm pretty new to this so that will hold me for a while :) <mbakke>ngz: no wait, 'checks/jobs.fish' fails with "Found existing zombie processes. Clean up zombies before running this test." <ngz>Or simply drop the test. <mbakke>ngz: indeed, it built with --cores=1, I can patch it <ngz>(is it reproducible?) <mbakke>ngz: it failed on a 12-core and 3-core system, and the error message suggest that the test is not parallel-safe without a zombie reaper (which the build container lacks) <ngz>No, I meant: did you get the same hash? <mbakke>ngz: heh, when building with --rounds=2, the test failed in the second try, even with #:parallel-tests? <mbakke>ngz: in any case 'guix hash -rx' reports 1rh2dkbwghpb8xxy80marliy2qpn0c1vvmqqdi66v9a3a024ym4p for 'guix build --no-grafts fish' on current master <mrw>mbakke that worked well (container plus removing /bin/sh) in terms of allowing me to reproduce the failure. Thanks. <apteryx>for the record it had 63 days of uptime and was running a 5.15.6-gnu kernel <apteryx>it seems the device names have been shuffled, but otherwise the mounts seem OK <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.
***civodul` is now known as civodul