IRC channel logs
2025-04-08.log
back to list of logs
<Ironsmith>hummm i'm in a pickle. my keyboard's mcu is arm, but i don't see any arm cross compilers in the official guix repo, which makes sense assuming it's not FOSS. in this case what's the safest way to get and run a arm gcc cross compiler? would it be using guix shell --container? specifically i'm missing `arm-none-eabi-gcc` <lechner>ieure / Hi, does Librewolf know about browser.cache.disk.parent_directory ? <lechner>ieure / also, is there a recommended way to migrate from FF? <dstolfa>lechner: surely you can just import everything since it's basically firefox with a few tweaks? <ieure>lechner, Not sure what you mean about browser.cache.disk.parent_directory. <ieure>lechner, And yeah, it's the same format for everything, so you can copy the profile. Not sure if there's a profile importer thing or not. <lechner>ieure / I have a very slow home directory (NFS and encrypted) and a locally encrypted partition. How may I redirect the browser cache to the local drive? <ieure>lechner, That preference you mentioned seems like it'd work. <ieure>lechner, LibreWolf is Firefox without the nonsense, all the core stuff like that works the same. <Kolev>Note that upstream LibreWolf uses DRM. Guix build of LibreWolf turns that off. <ieure>Upstream LibreWolf compiles in Widevine DRM, but disables it by default. The Guix package builds without it. <Ironsmith>i migrated from ff to librewolf recently, all i did was start up librewolf, noted down the profile folder name, renamed it to something else, then copied over my ff profile folder, renaming it to the librewolf generated one <Ironsmith>the folder name is something like ~/.librewolf/xxxxxxxx.default <Ironsmith>so `mv ~/.librewolf/xxxxxxxx.default ~/.librewolf/xxxxxxxx.default.old` then `mv path/to/ff/profile/yyyyyyyy.default mv ~/.librewolf/xxxxxxxx.default` while librewolf is closed of course <ieure>lechner, For-pay streaming video sites use DRM, if you don't use those, then probably not. <Kolev>I used to use Spectrum TV on the web. <lechner>Okay, I see the bar sometimes like on CNN but never clicked it <lechner>it would be a big step for me. i have used FF for nearly twenty years <ieure>It is unfortunate that Mozilla leadership has no idea what their product is, or who their users are. <lechner>Mozilla lost so much market share. PG&E stopped supporting Firefox---perhaps because they use a Microhero web framework---although it still seems to work for now <lechner>ieure / my FF profile is 1.8 GB. what is yours (or anyone else's) please? <trannus_aran>folks who use linux-libre (esp. laptop users), what network card or wlan usb adapters do you use? <lfam>trannus_aran: Since nobody who uses a WLAN adapter answered you, I'll say that you can be sure the adapters from thinkpenguin.com and tehnoetic.com will work <lfam>It's basically all ath9k with Atheros 802.11n chipsets <apteryx>hello, Guix! If someone is inclined to run their own IRCd (server), we now have an ngircd-service-type with most of ngIRCd configuration flags configurable. Let me know if you find any problem with it. <trannus_aran>Anyone have a tl;dr for what the difference between a project's guix.scm and manifest.scm are? Both look like they're for creating packages? <futurile>trannus_aran: manifest.scm is a manifest file (list of packages) activated with 'guix shell'. <futurile>trannus_aran: guix.scm is a package definition, normally used in a software project to package up the software for testing e.g. your own software dev <Rutherther>guix.scm can return a list of packages, it's not true that it has to be just one package definition. The resulting shell will have the list of the packages inside of it <Rutherther>manifest.scm can have a package definition and you can expose it inside of the manifest <Rutherther>the important difference between guix.scm and manifest.scm is that one is a simple list of packages, while the other is a manifest. So with manifests you have all the nicesities of easily referring to packages by their name (specifications) or easily making a development manifest (getting dependencies of a package rather than the package itself in the shell) - see specifications->manifest, package->development-manifest. Not that this wouldn't be... <Rutherther>the important difference between guix.scm and manifest.scm is that one is a simple list of packages, while the other is a manifest. So with manifests you have all the nicesities of easily referring to packages by their name (specifications) or easily making a development manifest (getting dependencies of a package rather than the package itself in the shell) - see specifications->manifest, package->development-manifest. Not that this wouldn't be... <futurile>Rutherther: did I say it has to return a single package somewhere? <Rutherther>and said that manifest is a 'list of packages', saying that is the difference, implying the other is not a list of packages <yelninei>sneek later tell janneke: It seems to work, i get a PASS: test-pthread_sigmask1 <futurile>fair enough, I was more wondering if I'd said it in the blog post <futurile>Cool! Thanks for looking at it. I wish we could get more people using guix.scm in their projects. <yelninei>sneek later tell janneke: Things left: ENOTDIR in the symlink tests, figure out what to do with --disable-year2038 , either upgrade mach/hurd or downgrade automake-boot0 <nigko>Rutherther: I found the culprit of the "Ignoring error while stopping ..." message in the system logs on my machine. It was qemu-binfmt service. When I disable this service the message disappears. Am I correct that the "Filesystems not unmounted on reboot" bug is not relevant here? <sneek>Welcome back nigko, you have 1 message! <sneek>nigko, lfam says: Yeah, for the way that the kernel generates a source of randomness (using a CSPRNG), it's considered somewhat important to preserve some entropy across boots, because otherwise you don't have much entropy available when booting <Rutherther>nigko: if you're getting the bug even without that service, I would think it's not relevant. But if you don't have that information, I can't say for sure... <Rutherther>if your /gnu/store is being used, I would think a program is running, using something from the store, so it could be a service not stopping... but that might be wrong <nigko>Rutherther: Thanks! I'll check. <Rutherther>although wait... I haven't realized it was the qemu-binfmt service. With that one, similarly to stuff like urandom, I don't thnk it can be related as it isn't really running anything, just something on start and on stop <nigko>Rutherther: BTW the problem with tlp service was exactly the same as with urandom-seed: the destructor returns #t on success instead of #f. Here is the patch that fixes it https://issues.guix.gnu.org/77629. <Rutherther>heh. Good that you're fixing more bugs with your investigation! <hanker>What's the status of Dart/Flutter on Guix? <futurile>hmm I wonder if someone changed guix lint recently, it seems really slow now <futurile>takes ages evaluating the descriptions/synopsis <jlicht>I could be wrong, but I thought I saw some patches flying around wrt the CVE checking <jlicht>ah never mind if it's not about CVE checking, I said nothing <futurile>it should probably do some sort of caching, it downloads the cve db every time, which is quite slow if you're on hotel wifi heh heh <nigko>Rutherther: When I disable qemu-binfmt service the 'Clearing orphaned inodes' messages no longer appear on boot screen after reconfigure and reboot. <Rutherther>I also use qemu binfmt btw and I don't experience the bug <jlicht>hey civodul! Thanks for all the recent shepherd improvements <olndrxyz>Hi, how do I add a variable which contains a list of services to the services list? Rutherther a few days ago suggested me to add something like (services (append (list...) my-variable (modify-services %base-services...)) but I keep getting the error "services field must contain a list of services. My variable is declared in a module with (define my-variable (list (service foo3-service-type) (service foo4-service-type))) <Rutherther>olndrxyz: please send the whole thing, your example in message seems fine, so you must've done something other way than you are showing it here <andreas-e>Maybe my-variable is not properly imported into the context where you use "append"? <andreas-e>The line looks good, but your wording "in a module" sounds suspicious :) <Rutherther>olndrxyz: please send the whole thing, your example in message seems fine, so you must've done something other way than you are showing it here <identity>olndrxyz: try evaluating the append expression inside `guix repl` <civodul>cbaines, andreas-e: i’ll have to do a hard reboot of bayfront (i restart nginx…) <civodul>interesting, i restarted nginx several times on berlin yesterday and it went well <Rutherther>it definitely doesn't where it's supposed to, the way you outlined is in your message - before my-variable <olndrxyz>Rutherther: do you mean I should add a parenthesis at the end of the ntp service declaration? <Rutherther>yes, but also remove the one that's currently closing the list. Meaning you should move it, at the end of ntp service, yes <Rutherther>olndrxyz: right, that is because you have a problem in your xorg-custom, you have "(keyboard-layout keyboard-layout)" in there, which doesn't make sense. You probably just moved it out of your operating-system where the second keyboard-layout was referring to the operating-system's keyboard-layout. That doesn't hold here anymore because it was moved <Rutherther>so here keyboard-layout refers to a record constructor, meaning a procedure that you see mentioned in the error you've sent <Rutherther>(a struct is expected in the field keyboard-layout, but you're giving it a procedure) <olndrxyz>Rutherther: thank you, without that line the reconfiguration succeeds <nigko>Rutherther: The thing is that qemu-binfmt service writes references to the store to /proc/sys/fs/binfmt_misc/qemu-[architecture] files, but, according to system logs, file-system-/gnu/store is stopped before qemu-binfmt. Could it be the reason for the 'Ignoring error while stopping file-system-/gnu/store ...' messages in the system log and 'Clearing orphaned inodes' messages on the boot screen after reconfigure & reboot? <cbaines>civodul, I had another go at reproducing the shepherd/nginx issue in a VM with no success <cbaines>I have still got a machine I can experiment on though, is there a way to have shepherd be more verbose with the logs (apart from adding more logging to the code)? <Rutherther>nigko: I don't know actually, maybe? You could try adding requirement file-system-/gnu/store to the qemu-binfmt and see what happens then <nigko>Rutherther: Right, I am doing this now. <attila_lendvai>cbaines, i had patches that made it easier to introspect shepherd's internal state, mostly through more extensive and configurable logging. i needed it for hunting down a bug... sadly, civodul left it to bitrot because it was too "baroque". <nigko>Rutherther: Adding file-system-/gnu/store to the requirements completely solves the issue! Thanks! <Rutherther>nigko: the whole issue? as in you don't get any more unclean unmounts while rebooting after reconfigures? <Rutherther>that's great! On the other hand, I don't think it's the same thing as ieure is experiencing as they had this issue as well, but not qemu-binfmt. On the other hand I suppose we could have more problematic services like these <Rutherther>as for why it happens only on reconfigures for you, I think the order of the services can change after reconfigure (or more specifically after running upgrade-shepherd-services), so when a service would not have all requirements explicitly specified, it could happen that after reconfigure shepherd will try to stop it only after what it actually requires, whereas normally it stops before them <nigko>It also suggests that the order of order of stopping qemu-binfmt and file-system-/gnu/store can be arbitrary depending on the machine's set of services/configuration, so that some users experience the issue but some others don't. <futurile>I think Nicolas Graves is a collective; there's no way one human can create that many patches, I can't even build them at the same speed he sends them heh <andreas-e>The first name is an indication as well, probably a hint at Nicolas Bourbaki. <andreas-e>I found it amusing that they manage to test the limits of debbugs with respect to the number of patches in a series :) <futurile>oh no way - never heard of Nicolas Bourbaki - what a great Wikipedia page <futurile>yeah - I do think sometimes people should limit the series they send - my heart sank when I saw a Rust series with 166 patches - it will have to wait until I'm home again to build them all <futurile>somehow 10-20 feels like I'm making some progress! <civodul>cbaines: i don’t have a good idea; i capture the strace log this morning when i broke bayfront, but i haven’t taken a look yet <civodul>having a way to reproduce it in a VM would be valuable anyway because we could try random things <janneke>sneek: later tell yelninei: check, you saw these three things before, right? <sneek>Welcome back janneke, you have 2 messages! <sneek>janneke, yelninei says: It seems to work, i get a PASS: test-pthread_sigmask1 <sneek>janneke, yelninei says: Things left: ENOTDIR in the symlink tests, figure out what to do with --disable-year2038 , either upgrade mach/hurd or downgrade automake-boot0 <apteryx>would anyone know why a 'guix system vm' started with -nographic has such a buggy behavior? the cursor moves to wrong places, the number of columns/rows doesn't match the terminal, etc. <apteryx>it's barely usable. I must be doing something wrong? <apteryx>that's starting a 'guix system vm' with the -nographic option added in the GNOME console terminal emulator <apteryx>ah, 'TERM=linux /gnu/store/.../xxx-vm.sh seems' to help <apteryx>nevermind, it doesn't seem to help 'stty size' still shows it's at 24x80 <apteryx>I guess one has to manually punch the rows/columns values <apteryx>such as with 'stty rows 54 columns 238' inside the QEMU VM connect to a tty with -nographic. That's a limitation of tty apparently (they don't pass host terminal geometry) <nigko>Rutherther: I performed more reconfigure & reboot. It turns out that fixing qemu-binfmt service doesn't solve the 'Clearing orphaned inodes ...' boot messages, while it is certainly solves 'Ignoring error ...' in logs. 'Clearing orphaned inodes' appear on the boot screen (but not every time) after reconfigure even if qemu-binfmt service is disabled. <apteryx>mkdir-p/perms is not recursive, right? <apteryx>(meant as in chmod -R, for the permissions) <apteryx>neat, mumi is full of 'updated seconds ago' <andreas-e>When you work on an issue, some hours later I see it as having been treated seconds ago. <apteryx>I thought it was the new fast indexer + more aggressive debbugs data sync that was doing its magic <andreas-e>Maybe things have become better as well, I do not know! <andreas-e>It appears on the "Recent activity" page as seconds ago. <apteryx>indeed; is it a known bug? Arun is on fire. <apteryx>(meaning: fixing bugs faster than I can report them) <ieure>I think the front page of mumi is static and refreshed on a fixed frequency, so it was "seconds ago" whenever that happened. <andreas-e>I also do not know whether it depends on the time zone of your browser or if it is hard coded in the web page mumi serves. <ieure>I mean, I *do* want wasi-libc in Guix. <apteryx>(time->string (issue-last-updated issue)) in the `list-of-bugs` procedure <apteryx>since it appears to be elapsed time, the timezone shouldn't matter though, right? <apteryx>but maybe the issue is dated with the submitter's own time zone, that would confuse things <apteryx>looks like the time comes from the 'Date' email field <apteryx>looking at the bug data, date appears to be in epoch seconds, e.g. Date: 1615884062 <apteryx>that should be fine, if the epoch time was properly converted from a source date containing the timezone info <yelninei>janneke: yes these are not new. The symlink tests is the remaining failing gnulib test, i dont know what to about --disable-year2038 (relavant for other 32 bit targets as well) and am unsure how to resolve that our mach does not build with automake 1.17 (the normal gnumach and gnumach-headers got patched to uses automake 1.16.5 but not the boot0 ones. imo we should just update mach/hurd and friends to the latest snapshot instead) . <sneek>yelninei, you have 1 message! <sneek>yelninei, janneke says: check, you saw these three things before, right? <hiecaq>Hi guix, emacs-org-roam seems to be too old for the emacsql that was just updated to 4.3.0, which dropped the deprecated function `emacsql-process`. Updating emacs-org-roam to any commit newer than 0d51698839171faff6583bbacca4f1b018505f13 should fix that. I've only tested the latest commit though. <janneke>yelninei: it's been a while since (mig/)mach/hurd were updated, so yeah updating to the latest git tags makes sense before looking into anything else <Kabouik>autogen.sh seems to be a frequent match in the IRC logs, I'm reading. <Rutherther>Kabouik: autoconf/automake is used on *build* time, meaning it should go to native-inputs, not inputs <Kabouik>It was in my native-inputs, but the same issue persists. I am looking at the gpm packages in linux.scm which seems to do something to work around the shebang issue in autogen.sh <Kabouik>Will try to replicate the change with my abysmal Scheme knowledge. <lechner>Hi, does 'make' in the Guix source tree ignore SIGTERM? <Kabouik>So this gets rid of the autogen.sh shebang issue, but now I'm getting an "autoreconf not found", despite it being in native-inputs as well: https://0x0.st/8_YJ.txt <Rutherther>Kabouik: there is no need for manual patching as the source is patched automatically. As for the error, that is because you're missing "which" dependency. You need to actually check what the script is doing to see what assumption is wrong <Rutherther>that script says 'X is missing' doesn't always mean it's really missing, but maybe that it just can't find it <Rutherther>using which is quite unfortunate imo, especially since you can just do "autoreconf --version" or "type autoreconf" <Rutherther>and redirecting stderr to dev null even more so, because you don't get the actual error printed out <Kabouik>Thanks a lot, I see. So I can remove the custom phase and just add which as native-input, nice. <Kabouik>But those are issues in the original autoconf from the sources, right? I just want to package it, I think any improvements should come as PR to the source repo and not custom alterations from the Guix packaging, am I right? <Kabouik>But yeah, that sounds like an easy PR. I just didn't check that script and did not see the implications the implementation the dev has choosen would have. <Rutherther>it depends, in this case, yeah, probably PR to the source. But there could be cases where unnecessary dependency is added that is quite huge or uncommon and at that point it would seem to me a good idea to patch it in guix <Kabouik>Thanks a lot for pointing to the right direction. I checked for similar errors here in the logs and there were many matches, but presumably due to another issue that is perhaps now resolved. <Kabouik>I still fail to build the package because it hits a wall when trying to create /etc/nbfc (permission denied), but I assume it might be because I had nbfc installed already with this directory already present, though that sounds weird now that I write it (especially as that folder is empty). I'll try removing the old package and garbage collecting just in case. <Rutherther>it's because it ignores the PREFIX for that part, and uses BASEDIR <Kabouik>I have to go but will resume trying to package this tonight. Thanks, Rutherther. <Rutherther>no sorry, it's not really right, it doesn't even respect destdir. There is a hardcoded confdir = /etc. :( <Rutherther>changing "PREFIX" to "DESTDIR" will probably work though, but it's not really the same thing <Kabouik>Hum, but still, there is an existing package already in Guix and this wasn't an issue at the time. I doubt the sources have changed in that part between the old package and now (but I can check the old commit later tonight) <elevenkb>I don't know if this is on topic, but it's a quick question tho. <Kabouik>Actually confdir used to be $(PREFIX)/etc, interesting. Might be worth adding in the PR too. <lechner>Hi, why would I see this when running guix build? Could not find build log for '/gnu/store/rdlx8as8z51w63vbld0a7nwy8rkaqbsh-wasi-libc-25.drv'. <Rutherther>if so, you don't have /var/log/guix mounted, so it's not found <lechner>Rutherther / Okay, thanks! I am updating a patch and building on master, so I guess screen output is all I have <lechner>ieure / Okay, LibreWolf is definitely privacy friendly. In the Bytecode Alliance's Zulip instance, which I use only reluctantly, I see: Your computer's time zone differs from your Zulip profile. Update your time zone to Atlantic/Reykjavik? <Rutherther>lechner: the log is of course still available, it's just not available from the container <ieure>lechner, Yeah, this is part of the resist fingerprinting (RFP) behavior. <lechner>Hi, what version of clang does the variable of that name provide, please? I cannot tell from g/p/llvm.scm <Rutherther>'> scheme@(guix-user)> (package-version clang) $1 = "13.0.1"' :) <lechner>sneek / later ask apteryx / The test suite in #64211 uses Python. Do you really think it makes sense to declare Python as a prerequisite for building WASI? Isn't our package graph complicated enough? <ieure>I do wonder what the status of that is... I've been meaning to pull all the wasm stuff from nonguix into Guix proper, so we can enable sandboxing in the web browsers. <ieure>I have this all in my personal channel, I use it daily. <ieure>Things are a little iffy for that usecase, I tried updating it to the latest and LW doesn't build. <lechner>ieure / you also get clang (LLVM option parsing): Unknown command line argument '-wasm-enable-sjlj' ? <futurile>Anyone else getting a bad gateway from QA? <ieure>lechner, Are you asking about #64211? <lechner>ieure / yeah! btw, how may I adapt this Emacs setting to Librewolf, please? (customize-set-variable 'browse-url-browser-function #'browse-url-firefox) <ieure>lechner, Set browser-url-firefox-program to "librewolf". <lechner>ieure / thanks so much! i'm loving it <ieure>lechner, Yeah, it's on my to-do list, just haven't got to ti. <lechner>ieure / there is momentum if you reply today <ieure>I may have some time later today. <ieure>lechner, What would you like me to do, reply to your patch, send a v2 to the bug your patch is in, open a new bug, something else? <lechner>ieure / Please just send your package definition using my new g/p/wasi.scm file (for the Guile imports). No attribution needed, so please remove my copyright <lechner>ieure / i really didn't mean to delegate. i am offering the response to my bug as an opportunity to get your package definition accepted. mine was clearly deficient <ieure>lechner, Okay, thanks, I'll send it as a new patch series and mention in the bug for yours. <ieure>I don't think yours is deficient, just maybe we have different goals. <ieure>lechner, Clang in Guix builds with only support for the native architecture, I assume this is to ease bootstrapping. <lechner>ieure / yeah, that comment wasn't so useful. i meant merely the reference to "their" Clang <lechner>The comment about the WASM target also didn't relate to the question I posed there. Maybe it's called the X-Y problem <ieure>lechner, I think it was accurate, but unclear. I believe that flag is only supported on Clangs which have a WASM target, and since Guix's doesn't, that's why it doesn't work. <ieure>Savannah failure rollercoaster is severe today. <divansantana>guix on a foreign distro, how can I guix pull to a version that has substitutes available? So as to make updates quicker? <identity>divansantana: you can use the --commit option to pull in a specific commit <divansantana>identity: thank you. how do i know which commit has a lot of substitutes? <andreas-e>There is a feature called commit-with-substitutes or something like this, to be used in the channels file. I hope this is enough information to find it in the documentation :) <futurile>andreas-e: uh do you remember which bug# python-team was using to track their branch, you closed it to change the queue, and ofc I now can't find it in debbugs