<vagrantc>yeah, a bit confused about that as well ... <ngz>At least guix weather seems to test both servers now <muradm>is there a way to see guix weather for (operating-system ...) ? <pkill9>i think the python-pyside-2 package has the wrong version, it's set to 5.14.2.3 which looks like qt version, but the qt version it uses is 5.15 <muradm>i can see for manifest, but not for os <pkill9>oh maybe not, it's using python-shiboken-2 <pkill9>i guess that needs to be updated <iskarian>is there anyone around who is able to test `guix environment --pure --system=powerpc64le-linux --ad-hoc coreutils@8.32 -- stty -raw`? <iskarian>or even better, a native ppc64le system, to rule out emulation errors <ajarara>Is there a way to set environment variables in a system config? Trying to get zathura-pdf-mupdf to be seen by zathura. <ajarara>This works when I set manually export the zathura plugins env var. But I'd rather have that be in the system config instead of a bash profile. <pkill9>ajarara: it should be added to the profile if you install zathura along with zathura plugins <ajarara>install imperatively? It isn't, I've got both in the system config. <lispmacs>I like building with --no-substitutes as it makes me feel like I am more in control of my computing. I was wondering though if there was any real benefit, as far as that goes, from --no-grafts. The grafts are just updating library references right, or is there more to it? <tpefreedom>Does the guix system installer automatically recognize usb wifi dongles? ***ashkitte1 is now known as ashkitten-irc
***iskarian is now known as Guest1654
<nckx>lispmacs: <The grafts are just updating library references right> Store references in general; often to libraries but can be to anything (external helper executable, data file, …) <nckx>lispmacs: <any real benefit […] from --no-grafts> Benefits? It means --no-security-fixes. What benefits? :) <nckx>lispmacs: With --no-grafts you will be running software known to contain security holes. It is not a reasonable way to exercise control over your computing. <gaston`>I finally got Guix to work with my proxy at work. So messy. Now, I am passing the environment variables for http_proxy and https_proxy to the daemon service in systemd. However, when I log out of work, of course the proxy isn't necessary anymore. I would need to delete the env vars and reload. Anyone know of a good solution for this? <efraim>you could have two daemons, and have guix-daemon-work inherit from guix-daemon.service (assuming that's possible) and only add the http_proxy and https_proxy <efraim>and then switch between the two as needed <gaston`>OK cool, I'll try that. Thanks for the quick reply. <gaston`>@efraim, this seems to have worked. Didn't realize you could spawn multiple daemons. I'll have to read up some more. Thanks again! <kitzman>hm, anyone experienced issues with mime or gdk-pixbuf? i.e i get an error while trying to open a file picker in a gtk browser. it's not a guix-only system, but i use guix exclusively for desktop (wayland, sway, etc) <kitzman>when i have gdk-pixbuf installed in my profile, guix's mime update fails <pkill9>are there any examples of packaged java applications? <efraim>doh, my idea was to have one daemon at a time <nckx>Now gaston gets to learn about GUIX_DAEMON_SOCKET I guess. <efraim>sneek: later tell gaston` you need to only have one instance of guix-daemon running at a time. run guix-daemon-work at work and guix-daemon otherwise, but only one at a time. <bricewge>How to use warn-about-deprecation? Especially the properties argument <euandreh>What drives the decision of having .po files per language+country vs just per country? I see we have po/guix/pt_BR.po instead of po/guix/pt.po, but not the same for other languages. <euandreh>Is it the translation team that jumps in and makes that call? <nckx>Per country? How would that work? <euandreh>nckx: the "BR" part in pt_BR.po is the country part. <nckx>Not how translations can be ‘per country’. <nckx>Is BE.po nl_BE, or fr_BE? *nckx is baking b-day brownies. <euandreh>If you're in Belgium with the computer set to french, I guess the most appropriate translation would be the fr.po <nckx>I still don't understand, sorry. :) <dstolfa>nckx: oh! is it your bday today, or someone in the family? :) <euandreh>I mistyped, it wasn't "per country", but "per language" <euandreh>So let me rephrase it: when do we choose to go "fr.po" vs "fr_BE.po"? <nckx>euandreh: I think ‘pt_BR’ *is* the language. It's not the same as ‘pt’, after all. <euandreh>Well, pt_PT is just another variation of portuguese <nckx>Why force it to be the same though? <nckx>I'm not sure that claim is at all correct but I don't speak either. <euandreh>No good reason to unify them, just a desire to better understand what triggers the decision <nckx>For an example that I can guarantee leaves no room for debate: zh_CN and zh_TW are not the same language. xx_YY is not ‘language+country’. <euandreh>From what I'm understanding, the default strategy is to go with "$lang.po", unless country variations are relevant enough to merit a "$lang_$COUNTRY.po" <nckx>euandreh: Basically, yeah. <nckx>Although I don't know ‘who’ decides that. It's all very ad hoc… <nckx>Such a polite word for a mess. <euandreh>Actually I'd imagine that translation teams would themselves feel very discomfortable when it isn't quite right <euandreh>Like even proposing a single "zh.po" would prompt a response saying: "this won't work, can't we make a zn_CH.po instead? I don't speak zn_TW." <nckx>And that's the real crux. This stuff is so intimately tied to identity and belonging. To seek ‘technical’/algorithmic order here is misguided madness. <nckx>(Not saying you are; clueless people have.) <nckx>Swiss Chinese minority rights are human rights. <nckx>euandreh: Like, I'm sure there's a nonzero number of people who are fine with ‘nothing’ de facto supporting nl_BE and using nl_NL instead — but only because nl_BE *exists*. If someone tomorrow would decree a single ‘nl’ alias for nl_NL, *someone* would be offended. <nckx>Now nl_ is an extremely tame & rather irrelevant example, but extrapolate that to huge demographics that are strongly invested in their identity and it won't end well. <leoprikler>is gettext not like "okay, fist we try ${LANG}_${COUNTRY}, then ${LANG} only"? <euandreh>nckx: That's fascinating! How this relates to identity/belonging really is quite subtle, but very powerful. <euandreh>leoprikler: I'm actually not sure. It makes sense that it would behave like that. <euandreh>On the topic of gettext, I was recently made aware that a version of it is on its way into the POSIX standard, let me get that link <nckx>Probably with a similar algorithm in the other direction (user has en_GB set, try en_GB, nope, try en, nope, try en_US, OK) if it's like anything else. <euandreh>Now I'm curious, I'll read gettext's documentation on how it does that <nckx>euandreh: Apart from a ‘…POSIX? Who cares?’ double-take, that's great news. Almost everything else is worse. <euandreh>Yeah, I feel gettext really is best-in-class on this <euandreh>A de-facto standard, may be promoted to an official standard <dstolfa>i don't think a single OS actually fully conforms to it <euandreh>I don't think either. The thing about POSIX is that it is the only hope I have to write software that isn't coupled with an OS <dstolfa>and often, you still end up with OS-dependent things :( <dstolfa>because the things that are in posix are just awful and slow at times <nckx>Now epoll, that should be POSIX. <dstolfa>eh, epoll is pretty awful in many ways <dstolfa>i'd argue none of the current mechanisms should be standard <dstolfa>they all suffer from some pretty fundamental issues <nckx>OK, fair, it's just better than kqueue by a mile. <dstolfa>kqueue is way better at writing event loops that take more general kernel events and modify theem *euandreh opens some manpages to learn about epoll and friends <nckx>I agree with exactly the opposite of that last statement. <dstolfa>whereas epoll is more focused, but extending it is basically adding a new system call and you need to work with like 10 different interfaces <nckx>But it's fine, I'm not in a mood to discuss *looks under bed* epoll. <dstolfa>nckx: i mean, i guess it depends on what you're doing :D <nckx>dstolfa: <whereas…> What's interesting is I would have written the exact opposite of that, that is with epoll & kqueue swapped. <dstolfa>i've used both quite extensively for transactional distribution of programs and found kqueue much less painful for that task (also found it less painful to monitor directories than inotify since inotify assumes trees which breaks on hardlinks) <nckx>So we've obviously both Seen Things. <dstolfa>i think we can both agree that neither should be "the gold standard" and someone should just find a better thing <dstolfa>nckx: i could work on it, but i don't feel like being yelled at by both the linux and *BSD people about "why should we replace it" :( <dstolfa>nckx: once we're all using hurd, all of this will be way easier to swap! <nckx>My freeze-dried corpse rejoices with delight. <nckx>I mean I'm genuinely looking forward to the Hurd, I just expect to be doing so for a very long time. <dstolfa>tbh, it's probably easier to just use libnotify than worry about the KPI for this <dstolfa>though i guess it might become somewhat usable as a niche desktop at some point when SMP and 64-bit support is done? <reduce>It seems to me that the slow progress of Hurd demonstrates that the academics were wrong, microkernel is NOT the way to go <dstolfa>reduce: microkernels have to main problems: (1) IPC has a pretty significant performance impact on flat memory architectures where you can't safely do shared memory across processes for security reasons; (2) debugging is somewhat a pain due to said IPC <nckx>Thing is, I can imagine that much better if something were to happen™ to Linux. I don't want something to happen to Linux. There's a good lot of things I hate about Linux, but I love it. <dstolfa>these problems can be resolved, but they also require different hardware from what we have today. we might get that hardware in 5-10 years, we might not <lispmacs>just browsing Wikipedia, aren't there a few microkernels and microkernel OSes that are pretty well developed and active? <dstolfa>mm, sure, but they're used in somewhat specialized environments and academic <dstolfa>it would be naive to say that we have a microkernel-based OS that is viable to put on servers and as a daily driver for general purpose things <dstolfa>ultimately, those will always be on something that is best interfaced with the current hardware in a user-friendly way, and currently that seems to be unix-like operating systems since the hardware since a PDP-11 was made pretty much to run C and unix <lispmacs>I was just curious: if a package is only required to *build* (not run) a package in your profile, is it preserved by the GC? <nckx>lispmacs: Not by default. <nckx>--gc-keep-derivations=yes --gc-keep-outputs=yes can alter the deal. <lispmacs>would that mean that, e.g., if you had a package that depends on llvm, and you ran GC regularly, you would have to rebuild llvm everytime? <dstolfa>nckx: this motivated me to get some hurd testing in, i now have a childhurd to test things i want :P <nckx>lispmacs: If the package has llvm as an input, and nothing keeps a reference to llvm, and those daemon options aren't set. <lispmacs>--gc-keep-derivations=yes is the default, the manual says, so only --gc-keep-outputs is necessary? <lispmacs>there are options that must be passed to the guix daemon, not to the `guix gc' command? <lispmacs>is that something u can set in your system config? <ixmpp>sneek: later tell abcdw hey so, i only just realised when i tried out zsh, guix-home doesn't manage to do the on-first-login thing properly with fish as the user shell <dstolfa>does anyone have a non-volatile hurd VM running in guix? i keep getting "invalid G-expression input" for the one that was recommended in the docs <dstolfa>ah... the (const "/path/to/hurd.img") is wrong -- needs to be without the const <dstolfa>and now it's broken on secret service: retrying connection [...] <minikN>Hello. I would like to source $HOME/.profile whenever I log in using slim. How can I do that? <minikN>Actually let me rephrase, every time I login (either via slim or in a tty) <drakonis>minikN: have you tried adding it to your .bash_profile? <minikN>drakonis: No, I use zsh. Sorry I didn't mention that. ***Antlers is now known as antlers
<drakonis>to be fair, the answer here is to check out how to do this on a regular linux distribution then figure out how to do the same in here <minikN>on a regular distro I'd just edit /etc/profile I guess. <muradm>where to get help for this: Jun 20 15:32:19 localhost vmunix: [11066.049365] DMAR: [DMA Write] Request device [00:02.0] PASID ffffffff fault addr eebf0000 [fault reason 07] Next page table ptr is invalid ***hiphish is now known as HiPhish
<HiPhish>Hello, I am trying to contribute a new package definition, but I cannot build Guix locally. <HiPhish>I did `guix environment --pure guix` to set up the environment, `./configure --localstatedir=/var` and then `make` <HiPhish>However, the `make` part fails because Texinfo cannot find the nodes. I get a ton of messages like this: <HiPhish>doc/contributing.de.texi:1682: @pxref reference to nonexistent node `Synopses <HiPhish>The files obviously exist. Is there some other step I am missing? Some environment variable that might be messing with Texinfo? <ngz>You need to ./boostrap first, don't you? <ngz>maybe make clean and start again from configure <HiPhish>I even did `make clean; make distclean` <HiPhish>I'll just try throwing away the entire repo, brb <ngz>hmmm. That's a bit extreme. <HiPhish>I am on Void Linux, could it be an issue with the distro? <dstolfa>i don't really know, sorry. it definitely could be the distro, but it would probably be worth chasing down from the guix side as it's meant to work on foreign distros <dstolfa>just to check, is this glibc or musl void? <HiPhish>I did not want to do weird experiments with musl; it's cool that you can do it, but it's not for me. <HiPhish>I am doing `guix pull` now, maybe my Guix package definition is out of sync with the master branch. <rekado>HiPhish: sounds like a regression. Someone probably broke the documentation. <HiPhish>I had this same problem a couple of week ago as well <rekado>it was also reported a few days ago by mschilli <HiPhish>I get the following error from the configure script: Makefile.am:716: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS <HiPhish>OK, I'll just have to file a bug report then <itismyfirstday>is there anywhere to see the current status of "make check" on current master branch of guix? or should they always be all passing? <itismyfirstday>(I ask, because I see lots of fails, and did in a previous version as well) <dstolfa>yes, i use an external ath9k_htc device <Franciman>I am a bit reluctant because I also need an usb-c -> usb adapter <dstolfa>Franciman: so, usually i like carrying things with my laptop. i ended up buying two laptop sleeves that i stuck to the lid and just keep the adapter in there, along with all the other stuff i carry <dstolfa>://www.amazon.co.uk/Newseego-Portable-Accessories-Organizer-Earphones/dp/B08JLRXDB3 i found that something like this does the job *dstolfa can't copy paste, hands too cold <dstolfa>UK, it's 10 in my room at the moment *Franciman is burning at 30°C <dstolfa>anyway, i found 2 of these pockets pretty handy, and i just pack the adapter & external wifi in there along with other stuff <ixmpp>Ok i LOVE that guix gc shows size freed as it goes <nckx>It's not entirely… accurate, but it's nice. <nckx>(And it's just some hard-link or similar accounting confusion; nothing that couldn't be fixed.)