<KE0VVT>Is (keyboard-layout "gb" "dvorak") valid? <the_tubular>Anyone know how to setup Mac randomizer with Network Manager using guix ? <the_tubular>OR maybe even without network manager, but I feel like it's pretty important to guix <paladhammika>the_tubular: also interested in doing this for myself just haven't done so yet. you would have to make a shepherd service. <paladhammika>the_tubular: look in the reference manual for g-expressions and shepherd root services. you'll have to make a "one shot" service which runs at boot. <the_tubular>I'll give it a shot, but I'm still confused about the difference between shepherd services and services <paladhammika>the_tubular: i don't think there is a difference -- someone correct me if I'm wrong ***Xenguy_ is now known as Xenguy
<jaft>Hullo! I was wondering if anyone has had any success with having their Android phones get detected? I'm using GVFS with Thunar; I originally posted about my issue at https://www.reddit.com/r/GUIX/comments/s55e8m/smartphone_detection_with_gvfs/ and the gist was that I noticed that my udev 69-libmtp.rules file on my Debian machine had a ton more entries than the one served up by Guix. With a little help, I was able to add an updated <jaft>version, with everything the Debian machine has, to udev-rules which caused Thunar to recognize my Android when I plugged it in but was still unable to mount it, any. <jaft>Clicking on the device resulted in no interaction and right-clicking the listed device and manually selecting "Mount" resulted in the message, "No mtp devices found," still. I haven't gotten anywhere beyond that, sadly. ***califax- is now known as califax
<apteryx>jaft: there's an android-udev-rules package in guix you can use to extend the udev service <apteryx>that should do it, although if your phone is very new, you may need to update the package first <jaft>Ah! That's fantastic; I couldn't figure out where Debian was getting their device list from so, at the very least, it should avoid that issue, for me. I'm gonna try it out. Thnaks a ton! <apteryx>there should even be an example in 'info guix' about it <apteryx>info guix -> i udev-rules-service RET <apteryx>press space once, example should be in the middle of the screen <paladhammika>hello guix. i'm attempting to solve why no audio goes through my input. most of the suggestions I see online involve tweaking something in /etc/modprobe.d/ but no such directory exists in guix, are these files stored anywhere. ***sneek_ is now known as sneek
<munksgaard>Is there a way to convert a nix derivation to guix? ***aya is now known as gyara
<KE0VVT>I wish there was a standard scheme of naming system declaration files and home configuration files. <efraim>other than `guix shell` having special handling for guix.scm and manifest.scm you can use whatever you want. home-config.scm and system-config.scm are two that come to mind <roptat>"./test-build.sh: line 51: getopt: command not found" <roptat>I'm trying to fix test issues in ibus-anthy for taiju :) <roptat>looks difficult to provide all the things it requires <roptat>the first failure was easy to fix. It was looking for the current year in a file that stops at 2021 <roptat>yeah, and then it has some complex tests that require a HOME, additional python stuff... <efraim>test phase for guile-fibers took ~8 hours on riscv64, I'll look into cutting some of the massive test bits from it down by a bit <taiju>roptat: Are you sure? Thank you so much! <roptat>taiju, yeah, I'd like to get it working on my computer too :p <roptat>"ValueError: Namespace Gdk not available" that's from python, any ideas? <mbakke>roptat: perhaps you need pygobject or something in that vicinity? <taiju>roptat: I'm glad to hear this, because it is a must-have package for users who want to input Japanese in Guix. <roptat>it's already pygobject that gives me that message <roptat>so maybe it's because it doesn't have the right environment to use GDK/create a window or whatever <unmatched-paren>sometimes i can't boot, there's a ton more log messages, and when i did get to a bash prompt i couldn't run sway, so i guess kms or drm is broken or something? <roptat>ah, "make check" seems to do something wrong actually <jpoiret>unmatched-paren: you can't, unless you pin a past kernel version using an inferior <jpoiret>unmatched-paren: according to lwn.net, 5.15.20 just got released <jpoiret>it should the issue everyone is having <jpoiret>5.15.21 got released right after 5.15.20 to fix a bug in the former <jpoiret>but maybe those new versions fixed the bug you're having <jpoiret>5.16.5 is from the same release as 5.15.19 <jpoiret>i'm no kernel pro but the changelog doesn't seem promising <jpoiret>the only drm commit is reverted in 5.15.21, and it only touches hdmi related things <roptat>ok, getting further: (anthytest.py:3491): IBUS-WARNING **: 10:43:24.177: Unable to load /var/lib/dbus/machine-id: Failed to open file “/var/lib/dbus/machine-id”: No such file or directory <jpoiret>i'm running 5.15.18 currently, and am pretty scared to upgrade now :) let me try as well <jpoiret>i'll rollback if anything goes wrong <unmatched-paren>there's a lot of commits between 5.15.16 and 5.15.17, and a lot of them are drm-related <jpoiret>so if it breaks down at .19 that might pinpoint it <jpoiret>although i have to say that i'm running "that other kernel" <roptat>I feel like we really have to disable tests on that package... <roptat>I can't access /var/lib/dbus, right? <roptat>and I can't change that location, since it's hard-coded in dbus <rekado>roptat: you can start dbus for the tests <unmatched-paren>if we have different gpus and yours breaks it might not be the same problem :/ <jpoiret>hmmm, apologies, we don't have 5.15.19 yet in that other channel yet <roptat>rekado, yes I've done that, with dbus-run-session, but ibus still wants to read /var/lib/dbus/machine-id <roptat>I took inspiration from pipewire to run dbus-run-session -- xvbf-run -a -s ... make check <roptat>then I get this warning and AssertionError: ibus-daemon is not running <roptat>ah, setting HOME fixed the issue <roptat>and now it's stuck waiting for interaction... <gordon1>how to figure out why certain profile exists? i have this /gnu/store/ir0m129lbvr1f0yl0sh4bpp3q8d8rk9f-profile.drv, guix gc --referrers is empty for it but guix gc refuses to collect it as garbage <gordon1>btw there are bunch of such store entries that i struggle to find out the reason why they are still there <roptat>it's probably linked from /var/guix/profiles <civodul>gordon1: note that .drv is for "derivations", which are the build instructions to actually build the profile <gordon1>no, i checked everything that is in guix gc --list-roots as well as checking every symlink from /var/guix/profiles <gordon1>civodul: still doesn't answer the question why it still exists if it has no referrers <civodul>it exists because you didn't run the GC, i suppose <civodul>the GC would remove it (unless you're using the --gc-keep* options of guix-daemon) <civodul>but note that every time you run, say, "guix install ... --dry-run", it creates one of these profile.drv and in fact many other .drv files <gordon1>i did run gc before i made this check <gordon1>i have to run guix gc --list-roots under sudo to get _everything_ <gordon1>still not sure why this .drv has no referrers, i had to look inside the file itself to find out profile it belongs to <roptat>there's no referer because nothing depends on derivations <cbaines>plenty of derivations refer to other derivations (and thus depend on them) <cbaines>but not all derivations will have referrers <unmatched-paren>jpoiret: i've pinned the 5.15.16 kernel and everything works fine :) <unmatched-paren>all the problems i was having yesterday appear to actually have been kernel problems <gordon1>cbaines: then how to find out why it is not collected as garbage? there has to be a way that guix gc decides to keep it <gordon1>even more interesting, i have this dbus derivation /gnu/store/pqpnqcz1m1i6wg5d99wx1p5s43msqn9b-dbus-1.12.20.drv but no corresponding store item that contains dbus itself, i.e. no /gnu/store/longhash-dbus-1.12.20 meaning it never actually was executed, right? <gordon1>is there a way to check why particular file in /etc was created? <unmatched-paren>some startup log messages get printed in the way of the prompt though, can i stop that somehow? <unmatched-paren>it looks like this: "guix-aspire login: <various log messages>", but it doesn't actually get added to the prompt text (it's kind of hard to explain...) <jpoiret>unmatched-paren: yes, that's because the tty to which kernel messages are printed is tty1 <jpoiret>you should be able to change that I think <jpoiret>possibly, yes, I haven't tried myself <roptat>alright, now I get "Anthy: Failed to create profile directory", which is getpwuid(getuid())->pw_dir <roptat>I suppose this doesn't work inside the build environment? <unmatched-paren>changing the default tty worked for the ModemManager message, but there's still a few left: "Missing Free firmware (non-Free firmware loading is disabled)" and "Unable to load firmware /*(DEBLOBBED)*/ (-2)"; i presume that's because there's no firmware available for my wifi card (i'm using an thinkpenguin wifi adaptor) <brandhout>Hi ! I'm trying to package a newer version of DWM for guix. Everyting runs but I've got a problem with the freetype2 dependency. The config.mk of DWM has a hardcoded reference to /usr/include/freetype2 as Cflag. I need to substitute this with the guix freetype path $(guix build freetype). Does someone have an example of this use case or some <jpoiret>see basically any gnu/packages/*.scm file for a use of it <jpoiret>freedesktop.scm has one in the very first package <kozo[m]>KE0VVT: I think you have some misplaced placed () <kozo[m]>I’ve had that wall before saying bad structure <jpoiret>rather, in your services field, which should be a list, you've added (modify-services %desktop-services ...) <jpoiret>that isn't a service but a list of services <jpoiret>so inside your list of services, there's a list of services instead of a service <jpoiret>rather, since you're appending all your own services to %desktop-services, you should replace the %desktop-services with (modify-services %desktop-services ...) <KE0VVT>jpoiret: It already looks like I'm appending a list of services to %desktop-services. <jpoiret>yes but inside that list of services you're appending, i see (modify-services %desktop ...) <jpoiret>that gives a list of services, not just a service <KE0VVT>jpoiret: Thanks. Now, setuid with swaylock is having issues. guix system: error: #<<setuid-program> program: #<file-append #<package shadow@4.9 gnu/packages/admin.scm:806 7f083e4ad630> "/bin/passwd"> setuid?: #t setgid?: #f user: 0 group: 0>: invalid G-expression input <jpoiret>KE0VVT: do you have a bigger backtrace? <jpoiret>hmmm yeah, i just saw that it's an error that is caught in guix/ui.scm, so no backtrace <KE0VVT>jpoiret: c6b407c923253ac3e7ce8439b31f52ef94de7846 <jpoiret>by the way, if you only need to prepend new items to a list, i suggest using cons* instead <jpoiret>that'll avoid creating a new list just to traverse it and cons its elements to the next one <jpoiret>okay I see where the issue comes from <jpoiret>but I don't know why it would trigger <jpoiret>are you using a local guix checkout? <KE0VVT>jpoiret: I am not using a local Guix checkout. <jpoiret>i am able to build that part just fine <jpoiret>the only thing i can think of is mismatched ABI but that shouldn't happen with `guix pull`ed guixes <jpoiret>can you start `guix repl`, then do `(use-modules (gnu system setuid) (gnu packages base)) <RET> (setuid-program? (setuid-program (program (file-append hello "/bin/hello")))) <RET>` <jpoiret>ahhh but actually it's not this one that's responsible <jpoiret>I suggest opening a bug report, because it is very weird that this is happening <jpoiret>somehow, setuid-program? doesn't return #t for the elements of %setuid-programs <jpoiret>so the field sanitizer of setuid-programs tries to wrap it in a new (setuid-program (program ...)) for backward-compatibility, leading to the original setuid-program record being lowered by being inserted into a gexp, which isn't possible, hence the error <rekado>mbakke: commit e301f1a8ed11f9eacb2b7f525a7446dc00621a8b broke the ci.guix.gnu.org config <rekado>it’s not obvious to me how to fix it. <rekado>the nginx field is no more and we were using it <rekado>now it tells me “error: %zabbix-front-end-configuration-nginx: unbound variable” <rekado>I understand that this is now gone <rekado>but we also have a definition of %zabbix-nginx-server, which we used to pass to the nginx field of the zabbix front end service <mbakke>rekado: that's a funny usage, looking into it <civodul>rekado: would it be an option to add gcc-2.95 and glibc-2.2.5 to some other module? <rekado>where would you like me to move them? <civodul>commencement.scm is normally for things below the default gnu-build-system inputs <civodul>(also there shouldn't be any #:use-module (gnu packages commencement) IIRC) <civodul>rekado: i don't know, next to nhc, would it make sense? <rekado>gcc-2.95-wrapper is in commencement because it’s merely a wrapper around gcc-mesboot0. <rekado>there are no “#:use-module (gnu packages commencement)” lines; there are lazy references to commencement, though <civodul>so maybe it's fine after all, i didn't look carefully enough <civodul>my thought was that commencement.scm is crowded and a bit "special", so if we could avoid adding things not strictly needed for C bootstrapping, that'd be best <rekado>I could move the gcc-2.95-wrapper somewhere else. <rekado>I touched commencement to export three values; that’s probably what made the glibc diff look like I’m adding it to commencement. <KE0VVT>jpoiret: I'm using RDE, if that makes a difference. <jpoiret>KE0VVT: can you try `guix repl`, then inside that `(use-modules (gnu system) (gnu system setuid)) <RET> (map setuid-program? %setuid-programs) <RET>`? <KE0VVT>jpoiret: $1 = (#t #t #t #t #t #t #t #t #t #t #t #t #t #t) <jpoiret>i've got no ideas, you could open a bug report about it <civodul>rekado: do we need to export gcc-mesboot0? <rekado>I couldn’t otherwise import it from elsewhere <civodul>jpoiret, KE0VVT: perhaps worth reporting to rde folks first? <rekado>I don’t care for gcc-mesboot0 in particular, but I do need GCC 2.95. <civodul>so in that case, how 'bout adding gcc-2.95 as a "regular" package in gcc.scm? <civodul>perhaps that'll duplicate commencement.scm somewhat, or maybe commencement.scm could inherit from it? <jpoiret>civodul: possible, but I doubt it comes from there though <rekado>I started doing that and then stopped myself after going two thirds of the way. <jpoiret>I can see what's happening but I'm puzzled as to why that would happen <rekado>civodul: I stopped because gcc-mesboot0 inherits from another package in commencement and uses a bunch of native inputs that are only available in commencement. <rekado>so there would be quite a bit more old stuff that would have to be redeclared outside of commencement.scm <civodul>well we can also keep things this way :-) <rekado>at some point I just decided that this is the least ugly way of getting gcc-2.95. <civodul>it's just not great that we're exposing these bits <rekado>I can look at this again and see if there’s a way to build that GCC with slighter newer packages to avoid that commencement spill. <civodul>yeah let's see if we can come with ideas, but no rush <civodul>and actually, i should say that first and foremost, it's pretty impressive how far you got on that bumpy road <rekado>heh, far enough to see that there’s no actual road ahead… :) <samplet>My two cents is that it’s important to keep commencement.scm simple to streamline the C bootstrapping efforts, but using its GCC 2.95 for GHC 4 for now is probably fine. <civodul>started as a bumpy concrete road and ended as a muddy path? :-) <samplet>Also, yes, it’s super cool to see more work going into Haskell bootstrapping! <samplet>I have some (bitrotted) patches that simplify commencement.scm using modern Gash that I’d like to return to eventually. If GHC 4 gets in the way, I might complain a bit, but I’m sure I’ll survive. :) <MysteriousSilve4>hello! is there any rules for urls in `homepage`? can a website be linked if it requires javascript to view? <civodul>samplet: simplification would be much welcome! <civodul>MysteriousSilve4: hi! there are no particular rules <mbakke>is it possible to refer to other configuration fields within define-configuration, à la 'this-record'? <apteryx>it's a hack, until a better understanding/solution comes around <apteryx>mbakke: if it's based on (guix records), yes <civodul>apparently it is based on (guix records) <civodul>but this-records only works for thunked fields <apteryx>civodul: we've filled 15 TiB of compressed/raw NARs on the new 22 TiB array thus far; I think we should move swiftly to deprecate one of the compression schemes, it's too expensive at this point. <apteryx>if I understand, the compressed NARs get baked 'on demand' if someone requests it. So we'd need to issue a daemon update that drops support for one of the scheme (let's start with gzip). <apteryx>cbaines: I haven't reviewed yet your nar-herder (I intend to), but does it build compressed NARs ahead of time, or on demand like on Berlin? <civodul>apteryx: yes, i wrote about it on guix-devel yesterday <civodul>on berlin, nars are not really built "on demand" because Cuirass requests them ahead of time <apteryx>yes, thanks; I'm trying to refine my understanding of the cached NARs thing, and how zstd vs lzip gets choosen, etc. <civodul>it's chosen based on the current CPU/bandwidth usage *civodul goes afk for a bit <apteryx>so the build farm (guix-publish) service answers GET requests with a reply that lists all the available compressed NARs matching the requested package. <apteryx>and support has existing for lzip since the middle of 2019 <apteryx>seems we could already reconfigure berlin to advertize only lzip + zstd substitutes? <roptat>hey guix! again, don't forget to submit your talk/bof proposal for the guix-days! <roptat>we're looking for all sorts of topics related to guix <roptat>your personal experience, how you use guix for work, your cool projects related to guix, etc <roptat>a talk needs to be pre-recorded, with no drastic time constraints (between 15 and 45 minutes) <roptat>a bof session is just a discussion session about a topic that you will lead/facilitate <roptat>no need to prepare anything for a bof session. At this stage, it might be the easiest. If there's a topic you want to see during the guix days, it's the only way to make sure we'll talk about it ;) <vldn>somebody got platformio packaged up? <cbaines>apteryx, at the moment, the nar-herder doesn't really handle anything complex like nar compression. The actual creation of an lzip'ed nar occurs on the machine that built the thing (which is good for distributing the work and efficient sending over the network), and it's then sent back to the coordinator, which then runs a build success hook which contains the code to generate the narinfo file, and import the narinfo plus <cbaines>compressed nars in to the nar-herder database <cbaines>so, to directly answer your question, it's all ahead of time <apteryx>civodul: getting rid of gzip would be a saving of at least 6.5 TiB, according to 'du -sh /mnt/btrfs-pool/@cache/guix/publish/gzip' <apteryx>or about a third of the new array capacity <podiki[m]>roptat: thanks for the reminder! I've been meaning to send in talk proposal (my experiences going all-in on guix from nothing, 6 months later) <roptat>great! please send it as soon as possible! <cbaines>apteryx, as I understand guix publish, the compressed nars on disk are treated as a cache. So things should still function if they are deleted (it'll just mean the compressed nar is generated on request) <roptat>podiki[m], deadline for proposals is... tomorrow <roptat>and deadline for a video of the talk is this Saturday (Feb. 12) <cbaines>I think the guix publish cache has been treated as "storage" though, so there are probably cached compressed nars that correspond to store items no longer in the store, so deleting things from the cache might result in requests not being fulfilled <apteryx>and it is guix-publish itself which generates them, according to some heuristics and the compression field of 'guix-publish-configuration' (for berlin, (compression '(("gzip" 9) ("lzip" 9) ("zstd" 19)))) <podiki[m]>roptat: so says my org-mode deadline too.... better get on it! <apteryx>cbaines: if I understand, after removing gzip from the above configuration of 'guix-publish-configuration' for berlin, it wouldn't advertize gzip'd NARs anymore. <apteryx>(and the associated gzip cache files could be safely deleted) <apteryx>people running a daemon older than ~June 2019 wouldn't find any substitutes -- that seems reasonable; that's nearly 2 years, with the 1.3.0 release somewhere in the middle. <cbaines>that seems rather recent to me, although my sense of time has been warped in the past couple of years <cbaines>stopping providing gzip substitutes seems like a thing to plan, publically discuss a schedule for, then carry out <cbaines>just deleting the cached gzip substitutes, but still allowing them to be used seems more the thing to do as a way of reducing disk space usage <civodul>and that should happen after a release IMO because that's when people are more likely to update their daemon (or install a new one) <apteryx>we already had support for lzip in 1.3.0, no? <civodul>apteryx: also, we can't just "rm -rf /var/cache/guix/publish/gzip" because that would delete nars that are available *only* as gzip (from when lzip wasn't used) <apteryx>lzip was enabled CI-side in 993d33d7 (2019-06-11 229) <apteryx>does that mean that from that point in time, Cuirass has generated a lzip substitute as well as a gzip one for each derivation it built? <civodul>possibly ("guix publish" generates them) <apteryx>and the code responsible for that choice is in (guix scripts publish)? <civodul>but i guess instead of "rm -rf", we could selectively remove those that have both gzip and lzip <civodul>problem is that narinfos would still list both <civodul>so they would need to be changed and possibly resigned <rekado>apteryx: does the btrfs magic help at all? Or is nothing to expected from file system compression with already compressed files? <apteryx>civodul: where is the narinfos metadata stored? <whound>Can any one take look at the patches that I have submitted ? From 53683 to 53692. <civodul>apteryx: see "ls -i /var/cache/guix/publish/*/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32.narinfo" <mbakke>rekado: I think commit 326e08bf0f55409f040612001f73a2cc4091c159 fixes it <apteryx>civodul: seems a sed could get rid of the gzip lines in all narinfo files; you say these narinfo files are signed? <civodul>whound: thanks for the heads-up! one of the committers will look into it, but there's unfortunately a huge backlog <civodul>apteryx: yes, see the "Signature" line <apteryx>seems we'll need some custom Guile script to take care of it <apteryx>after we have all the /var/cache/ data moved to the Btrfs array, we can snapshot it, and experiment <whound>civodul: Just a question. How many main contributers are there ? I just wanted to know the core community size. <civodul>apteryx: looking at signed-string in (guix scripts publish), we're still signing the whole narinfo, including non-normative parts like the compressed file sizes/URLs <civodul>something we should fix at some point <civodul>apteryx: probably what matters most is the ability to turn off gzip for future substitutes, to limit growth <civodul>the existing nars are "just" a constant factor <apteryx>can we already do this by removing gzip in the guix-publish-configuration field used on berlin? <apteryx>I guess this would completely cut support for publishing the existing gzip'd nars, right? <civodul>apteryx: like i wrote, i think it's safer to do after a release, and once it's been prominently announced <civodul>the other day, i found that a colleague who uses Guix daily was running guix-daemon from 0.15.0 on their laptop (!) <civodul>it's the kind of setup that will break when we remove gzip <civodul>the stats i had in March 2021 suggest it's relatively rare; we should check again <mbakke>rekado: derp, I messed up a variable name, commit 7c75fff68b8cdfb0cd691e0b9f4e69a048217cc3 should really restore backwards compatibility <civodul>BTW, i wonder if people read "guix pull" news <zimoun>which package provides pdflatex.fmt? Other said, what are the minimal set of LaTeX packages for compiling something? I would like to avoid to download the BIG texlive <civodul>zimoun: re LaTeX, i think you can try texlive-bin + texlive-latex-base <zimoun>I did and I get an error, that’s why I asked. ;-) Hum, let try again if I missed something <zimoun>civodul: re news, the main reason I don’t is because I barely run “guix pull -l” because it is too long, because it displays the list of “new” packages. It is useless, I guess. <zimoun>civodul, re LaTeX, a font is missing. <rekado>zimoun: is a font missing or a fontmap? <zimoun>rekado: Font OT1/cmr/m/n/10.95=cmr10 at 10.95pt not loadable: Metric (TFM) file not found. <civodul>zimoun: you don't need to run "guix pull -l": the news are printed upon "guix pull" completion, and you can run "guix pull --news" to view the details <civodul>but i guess it remains inacessible for some reason <zimoun>civodul, yes. But usually, when I run “guix pull”, it is not the right moment to read the news. <zimoun>or, often I overlook at a news because I am focus on something else. <civodul>apteryx: --news prints the last news, so it's kinda like the GNOME notifications: you can look at them later :-) <apteryx>does it? it shows nothing for me currently <zimoun>apteryx: I think “guix pull -l” is currently useless. Except if you run “guix pull” everyday. For instance, mine is displaing 205 new packages and 538 packages upgraded, and it is like that for several generations. <apteryx>my guix is at ff14bc60e56fb0c6636da1da9a850b7b04abb367 <zimoun>and “guix pull -l” displays old news :-) <civodul>apteryx: then again, news entries are quite rare :-) <rekado>zimoun: that font is part of texlive-cm and it is included in texlive-base <apteryx>I'd be happy if the output was a stream of news, starting with latest, sectioned per revision, which I could read all in my pager <grimes34>Can I make a request for a package to be added to GNU Guix? <zimoun>apteryx:, civodul: “guix pull -l” is fitting the job for the news, but because it also display all packages, I cannot use it. Aside it is really long. <civodul>i agree that the list of packages has become boring at best <civodul>we should show it only under --details or something <zimoun>civodul, as you said, it is only the last news. <rekado>zimoun: you also do not need to install texlive-bin <zimoun>rekado: thanks. Retrying all with a fresh profile. :-) <rekado>texlive also creates caches in ~/.texlive*, so it’s a good idea to check and remove them <gnoo>how do i know the reverse dependencies of a service that is currently running ? <zimoun>civodul: I think regular user are doing at best “guix pull” once a week. git log --after 2022-01-24 --oneline | grep Update | wc -l returns 201. Therefore, the output of “guix pull -l” is useless, I guess. <KE0VVT>zimoun: It's hard to pull it all the time. <zimoun>201 is for 2 weeks, for the last week, it is 162. <zimoun>KE0VVT: yes, I agree. That’s my point. :-) <zimoun>rekado: on foreign, all fresh, “guix install texlive-base”, then “pdflatex foo.tex” returns Font OT1/cmr/m/n/10.95=cmr10 at 10.95pt not loadable: Metric (TFM) file not found. <civodul>zimoun: agreed; but what about --news? <lfam>civodul: Are you still experiencing the kernel panic with linux-libre 5.15.17+ <mbakke>rekado: zabbix was recently upgraded from 5.2 to 5.4, so you should restart zabbix-server after reconfiguring to get the new database schema, otherwise the front-end will act weird <lfam>Hm, no, I don't think so <lfam>I'm curious, are you using a thinkpad? <lfam>We are still "in the dark" about this issue, so I'm trying to gather some data <civodul>i could give it another try to try to get debugging info <civodul>but it's tricky because it hangs before syslogd is running <civodul>and presumably before userland is running <zimoun>civodul: --news displays only the news and changes for the last revision. I think it is fine as it is. Instead, it is --list-generations which displays too much <lfam>After many failed boots, I have sometimes noticed the final lines of a kernel panic trace, but not enough of it to learn anything. I don't know how I can access this trace <lfam>There's also some hints that it may be related to wireless drivers, wifi and / or bluetooth <lfam>I wonder if nckx's affected machine has any wireless technology in use <lfam>I think there was another problem in 5.15.16 related to nouveau / nvidia, but as far as I can tell, this is a separate issue <lfam>Because, I don't think any of us have nvidida cards and 5.15.16 works for us <mbakke>lfam: I have a Guix system configuration snippet that can assist with bisecting the kernel if you want to go that route <mbakke>lfam: does the problem occur on vanilla linux? <lfam>mbakke: I would like to bisect but I don't have access to capable hardware. The affected machine is a Thinkpad x200, so building the kernel takes many hours. And berlin spends most of its time in GC these days <lfam>But, maybe I could start bisection on the thinkpad and get a result eventually <lfam>Can you share the snippet :) <mbakke>lfam: you can offload to a more powerful machine, or download substitutes from it :) <lfam>I don't have access to such a machine :) <lfam>Usually, I would use berlin but, like I said, it's not an option currently <lfam>Not much to learn from that page, unfortunately <rekado>I’m again waiting for the GC lock to run “guix pull”… <lfam>There are lots of potentially relevant complaints on ask.fedoraproject.org, but unfortunately most of the complains are lacking relevant details such as kernel versions <podiki[m]>anyone have any nice tricks for getting the store path of something by executable name? <podiki[m]>currently going with dirname $(readlink $(which <thing>)) <lfam>Specifically, the fact that the system becomes unresponsive at different parts of the boot process each time; it's not deterministic, at least within the Shepherd boot process <lfam>And of course, with enough users who each have different configurations, a distro like Fedora will have a variety of "it's frozen" bugs at any given time <mbakke>lfam: then you just do 'git bisect X && guix system reconfigure ...' <zimoun>rekado: thanks for checking. Add itemize and does it fail? ***Guest42 is now known as davidl
<lfam>Yeah, that's the bug that's killing aarch64 support <cbaines>apteryx, if that behaviour is actually a bug in Guile, I guess it's going to be difficult to fix <cbaines>re-architecting the Cuirass workers to either use threads rather than forking, or fork using safer paths in Guile (open-pipe*, system*) <apteryx>aren't guile-fibers about threads? I thought the issue occurs before of guile-fibers, but I haven't delved into the specifics (yet). <lilyp>fibers are more lightweight than threads, but yeah, they're nondet if that's the problem <cbaines>apteryx, I don't think Cuirass uses fibers within the remote worker. <cbaines>THe Guile docs say forking is unsafe from a process with multiple threads <cbaines>and given Guile's GC uses threads, my guess is that if you're using the GC, you can't just call primitive-fork and expect it to always work fine <apteryx>hmm... Wouldn't that mean that using primitive-fork would be generally unsafe in Guile, as Guile can decide to run its GC anytime, right? <apteryx>that sounds like a bug in Guile :-/. Users of its API shouldn't worry about shooting themselves in the foot like that. I'll bring it into #guile. <cbaines>I think I had similar issues back when I wrote the job processing in the Guile data service <apteryx>neat; seems we have something actionable to work on. I'll reference this thread to the Guix discussion, thanks! <cbaines>The guix-data-service still uses primitive-fork, but calls execlp soon after in the new process, which I think is the important bit <apteryx>hmm, actually the problem would be forking in threads, rather spawning threads from forks <cbaines>maybe Guile's not always displaying the warning when it should <florhizome[m]>Hey guix, how can I just have guix home “register” a config file, so it will safe it in this generation and in the next ones, and I can use rollbacks on it, without letting guix do anything on the file content? ***darosior5 is now known as darosior
<cbaines>apteryx, actually looking at the Guile code, maybe it's not as related as I thought. The GC related thread is stopped before forking, so maybe there is only one running thread when Cuirass forks <efraim>apteryx: regarding frozen aarch64 build machines, anecdotally when I limit my pine64 to use 2 cores of the 4 I haven't gotten system lockups <cbaines>that said, I'm guessing there must be something related to what the Curiass remote workers are doing that triggers this <cbaines>I've had other GC issues with the Guix Build Coordinator agents, but I don't think I've had a lockup issue <apteryx>efraim: odd. Perhaps a useful data point. <rekado>sneek: later tell zimoun Yes, with itemize it fails because the tcrm1000 font file isn’t found. It’s provided by texlive-fonts-ec. <efraim>ok, finally got webrtc-audio-processing building on all architectures (except mips64el, don't have that one hooked up currently) <efraim>rekado: "Don't long for headers"? <Haider>General question, when I use profiles (manifest files) to install Emacs packages, dont actually showup in Emacs. However, If I install them as a global package in my /etc/config.scm they manage to show up. What am I doing wrong here? <efraim>do you have emacs in your profile or in /etc/config.scm? <Haider>Emacs is just installed using my config.scm <Haider>does emacs have to be installed locally using the profiles(manifests)? <rekado>efraim: this is Perl 5.14 from Guix Past <efraim>rekado: I figured as much the last time you were working on it <efraim>I also noticed that there's a ghc-4.08.2 release for powerpc-linux <jpoiret>Haider: yes, emacs has to be installed in the same profile as the emacs packages <jpoiret>this is because of how search-paths work in guix <Haider>Thank you. Will try that now (trying to make my system more reproducable and not use "use-package" as much) <jpoiret>basically, search-paths are something that belong to the package that uses them, here emacs, so you've got to have the base package installed along with its "plugins" for all of the search-paths to be computed properly <jpoiret>this ensures that if you do a `guix shell emacs somepackages`, you will have an emacs with only those packages available ***bdju_ is now known as bdju
<futurile>hmm I sent a patch and wanted to send some comments that didn't need to be in the git commit. It's resulted in two deb-bugs (#53859, #53860). What did I do wrong? I did: git send-email --compose ../001-blah.patch <jpoiret>futurile: you need debbugs to assign a bug # before you can send follow up emails <jpoiret>you'd then have to send to the NNNN@debbugs.gnu.org email address <Haider>yes, im back again. (sorry for all the nooby questions including this one) but for some reason, none of the packages installed by the profiles are actually accessable using a terminal. All of the profiles are active. <attila_lendvai>shouldn't the shepherd make-kill-destructor wait for the process to exit? without that `herd restart foo` restarts too early. <apteryx>I remember working around that with some waitpid in the stop for the jami-service-type <apteryx>I guess it's a rarely exercised condition in the service tests (the restart), or that it somehow doesn't matter for most services <the_tubular>jpoiret, umm didn't know about that emacs thing. I haven't test this out yet. <the_tubular>What if I install emacs with a manifest and with a config.scm <the_tubular>Will I be able to use every emacs-* packages installed with my config and in my manifest ? <jpoiret>now that i think about it, it should since activating a profile only extends the env vars not override them <the_tubular>I'll definitely test this out. But my VMs are down at the moment...! <apteryx>rekado: thanks for fiing the texlive font maps; I have this in my local todo: "** TODO LaTeX updmap, hyphen, etc profile hook" <apteryx>seems you took care of the first item :-). <the_tubular>Just to make sure I understand right, as long as I have emacs in my system config and my manifest, I should be able to use emacs "plugins' (I don't know what they are called) that are both in my system config and my manifest ? <jpoiret>the usual pitfall to avoid is that you need emacs to also be installed in the profiles that add emacs packages for the env variable to be updated <pkal>What is the easiest way to check out the source of a guix package? <jpoiret>pkal: what do you mean by "source"? the package definition in the guix sources, or the actual source code used to build the packaged? <pkal>jpoiret: I'd like to work on the source of a package to prepare a diff. What I am looking for is something like an imaginary command "guix hack foo" that downloads the source, check in out in the current directory and starts a shell with all the development dependencies installed. <pkal>Ideally if the package has a git source, then with a git checkout too <jpoiret>guix build -S package will give you the source in the store, that you can copy outside, but i'm not sure it will have the .git with it <jpoiret>starting the shell is just a matter of doing `guix shell -D package` <pkal>What is bothering me now is that guix shell -D is trying to build the package I am debugging. <KE0VVT>How do I set up a ReadyMedia/MiniDLNA service? <pkal>I figured it out, "-D -L . foo" is not the same as "-L . -D foo" ***califax- is now known as califax
<KE0VVT>Does anybody have a media server on Guix?