IRC channel logs
2023-01-08.log
back to list of logs
<rhn>I'll check what those substitutes are, thanks <rhn>for a router, all I need guix for is the 3 things: the ability to reproduce the same state elsewhere, the ability to change config files, and the ability to correctly restart services as the configs change <rekado>it wasn’t quite enough, unfortunately, but better than the very terse output I got from ,use(gnu packages compression) in the REPL <rekado>the final problem is java-brotli in (gnu packages compression) <rhn>being able to upgrade the image is a nice bonus, being able to install anything is a liability <rekado>java-brotli is there because it inherits from brotli. <rekado>but (gnu packages compression) is used by the new (gnu packages java-bootstrap) module <rekado>removing java-brotli from compression (and removing the import of (gnu packages java)) fixes the problem <rekado>while I’d like to move java-brotli to (gnu packages java-compression) I also feel bad about ripping it from its nest of brotli-adjacent package definitions (e.g. python-brotli). <rekado>and moving it would also mean that I cannot inherit from brotli in (gnu packages compression). <nckx>rhn: If you're using an image, I don't *think* it should contain poppler, but I can't say this with 100% certainty. But to be clear, there'll be plenty of other stuff you don't like. <rhn>maybe I was too pessimistic about the cruft, there's an SD card to use <nckx>Poppler would be used to build the image, on the build machine. <rhn>either way, the image must contain enough guix to be able to update configs, so I might be stuck with it <rhn>still better choice than the nix language D: <rhn>(even then, this is the first package in a long time that strongly requires a special manual) <rekado>since we also have (gnu packages python-compression) I feel that we should just move python-brotli and java-brotli away from their parent in (gnu packages compression). <KarlJoad>I have not set up auto-locking on my desktop yet, but the monitors go to sleep, and I always confuse the two. <rekado>use dice words password and retcon a story when you accidentally paste it. Nobody will notice. <rhn>hard to use a manager when the screen is locked <KarlJoad>Can I specify a package output by importing a package? Or do I need to use specification->package and folk? <vivien>Some day I was fed up that the screen would go black and the session will be locked instantly. So, I decided to lock the session 2 minutes after the screens goes black. Then some day I notice the screen is black, and start typing my password to unlock the session. It was still unlocked, and I sent my password to someone else :) <vivien>That’s why you don’t want to reuse passwords. <vivien>And now my session locks as soon as the screen goes black. <rekado>KarlJoad: what do you mean by “importing”? <vivien>Also an alternative for passwords is $(head -c 12 /dev/urandom | base64) <KarlJoad>Sorry, that did not make much sense. I meant I want to specify the specific output of a package without using specification->package or packages->manifest. In particular, I want the utils output of the bind package. <KarlJoad>vivien: I usually end up using pwgen, but that is also a good one. <vivien>Write it down in a small piece of paper that you carry with you for 8 days. Try and remember it. When you’re confident you can remember it, delete the paper. If someone saw your paper in the mean time, retry with a different password :) <vivien>If that’s for a work computer, make sure you remember it after a week-end before destroying the paper! <KarlJoad>It's just the standard password for my user on personal local machines. No business stuff. <KarlJoad>rekado: I did try (operating-system (packages `(,bind "utils"))), but that does not make things happy, because it is a tuple, not a package with output specified. <vivien>The obvious benefit of using $(head -c 12 /dev/urandom | base64) is that it could look like a URL token or something else deemed uninteresting, and it does not reveal anything about you. <rekado>KarlJoad: “packages” expects a list, no? <rekado>(packages (list `(,bind "utils"))) <rekado>I find quoting and unquoting a little distasteful in short phrases like this, so I’d do (packages (list (list bind "utils"))) <rekado>but (list (list …)) is also ugly <KarlJoad>rekado: It does, yes. My package list looks like `(,coreutils ,moreutils ,@`(bind "utils")) <rekado>re java-bootstrap: I’ll leave out the icedteas. This greatly simplifies things. <KarlJoad>I get the error (map1 (#<package binutils@2.37 gnu/packages/base.scm…> …)) (map1 ((#<procedure bind (_ _ #:optional _ . _)> "…") …)) <KarlJoad>That was what I thought would make it work, because packages->manifest takes in a list of tuples. <rekado>(list coreutils moreutils (list bind "utils")) <KarlJoad>Is that all that is needed to select a particular output in the OS package list? <rekado>package->manifest says: “Elements of PACKAGES can be either package objects or package/string tuples” <KarlJoad>I have not. I did not know that was an option. The manual is a little sparse on how to select outputs programmatically. <mirai>I'm thinking either assoc-ref or in the case of gexps, `pkg:lib' <KarlJoad>rekado: I tried (packages (list coreutils (list bind "utils))) and that did not build. <KarlJoad>mirai: I am not sure how to go about that one. <bjc>sneek: later tell civodul #60636 is there for you when you have a moment <vivien>Has anyone yet created an issue with name 'sneek, tell bugtitle <predict the issue number>'? <bjc>i cannot, in good faith, condone such a ticket being made. but i can, in good humor <vivien>At least the name is the title of the original email <vivien>More seriously though I don’t know how bugtitle reacts where there’s an issue number in the name. That could be legitimate, although there aren’t any issues like that currently opened. <mirai>now I'm curious how bugtitle handles recursion as well <acrow>sneek: tell vagrantc The problem is symlinks within the source tree are not, currently, appropriately handled. see, eg u-boot/.../arch/xtensa/dts/include/dts-include <sneek>vagrantc, acrow says: The problem is symlinks within the source tree are not, currently, appropriately handled. see, eg u-boot/.../arch/xtensa/dts/include/dts-include <guix_noob>Hey Guix! I wonder if it's possible to install package in a running guix shell env? Can't find any info about that <gnucode>guix_noob: I believe so. "guix shell coreutils -- ls" <fr33zing>When I do `guix install some_package`, where does that go? Does that go in a scheme file somewhere? <trevdev[m]>Can anyone give me a tip for how to find dynamic linked library inputs? I'm trying to resolve these libs and I have no idea what package/output folder they come from <trevdev[m]>I know these are gcc/c++ or related libs but when I attempt to use them as inputs for something like patchelf, I crash and burn <efraim>sneek: later tell vagrant don't worry about Guix's mips port, it targeted the loongson 2F specifically and is long deprecated. <trevdev[m]>lilyp: and gcc. I can't seem to grok how I'm implementing the inputs incorrectly. <lilyp>I'm not sure what you mean by that, but if it's about getting the right command line parameters to patchelf, those shouldn't be too hard to find out from the manual <lilyp>in particular, you have to patch the rpath so that libgcc_s.so is found, which is done via --set-rpath <lilyp>alternatively, you could try setting up an FHS container <bienjensu>Hey. I'm having some trouble setting up emacs-exwm with emacs-next. My guix profile points to the correct emacs version, but emacs-exwm seems to be built with emacs 28. I'm basically trying to figure out how to override the emacs-exwm package definition to use emacs-next instead of emacs. <yarl>Do you mind if I ask (learning macros) in guix/store.scm on (define-syntax define-enumerate-type ...) why declaring the names as literals for (define-syntax name->int) is important? <unmatched-paren>i understand the monads explanation given a few days ago, and i get that monadic expressions return deferred computations. what still escapes me, though, is why the store needs to be represented by a monad in the first place. <joe75>hi is it possible to enable binary packages instead of compiling from source? <yarl>unmatched-paren: I remember from a conference I heard (past guix days I think) someone said that it is not _needed_, it's just that someone "liked" monads and thought it would be a good API there. Indeed, its purpose (as I understand it) is to keep unpure computations separated. <joe75>even on a install? last time i installed it took a few hours to install <unmatched-paren>i understand why mdo forms are useful in fully pure languages like haskell <vivien>unmatched-paren, your let form is not the equivalent of the mlet form <vivien>In the mlet form, nothing is computed yet <vivien>In the let form, it is as if you ran the mlet expression within (run-with-store …) <vivien>So, you cannot compose the let forms, but you can compose the mlet forms <vivien>You would compare the mlet form with (lambda (store) ...) <vivien>But writing that many lambda expressions is confusing :) <vivien>JavaScript did a good job of censoring the word "monad" when they introduced their async/await syntax <jpoiret>It's just like the reader monad: you could pass the argument down the line to every other procedure and it would work just as well, but you want to avoid that <jpoiret>Using the reader monad you can make it seem as though there is global state <rekado>sneek: later tell KarlJoad that’s because the package variable is called “ics-bind”, not “bind”. <tex_milan>why gcc-toolchain doesn't provide cc executable/link? clang-toolchain does, but is currently broken on guix. <tex_milan>attila_lendvai: thanks, I fully agree with your comments in the path! It would be nice to have it! <tex_milan>attila_lendvai: now what to do to get it? create a derivation of gcc-toolchain with this change? <attila_lendvai>tex_milan, the standard thing you need to do to use a fork of the guix channel (see manual). i don't rely on this specific commit, but i have a few branches that i merge together into one and use it instead of guix proper to test whether my changes break anything. <davidl>HAs anyone tried installing GuixSD on a librem5? <davidl>(and got basic things to work, like calling and texting) <dcz_>davidl: not that I know of, but there's someone on the forum trying to debug NixOS <tex_milan>is it possible to use guix-home (or system configuration) to create s symlink from gcc to cc? <davidl>dcz_: okay. Since it's a libre device, I wonder how much work it would actually take to get Guix working on that device. <dcz_>probably as much work as putting it on any other ARM board <dcz_>plus the mobile parts, depending on whether anyone added those packages yet <lechner>unmatched-paren / Hi, I think 'make -j' may probe the number of cores, and use them <cehteh>careful! make -j without a number traditionall means no bounds! <lechner>i think that's largely theoretical. i have never had an issue with a plain '-j'. the number of jobs is bounded by the finite number of build tasks any project is likely generate. at least on my system, slow disk access provides enough space for other tasks like X. if not, it may be more convenient to use 'nice' <trevdev[m]>lilyp: Thanks for trying to help. I've raised a help ticket with non-gnu as it is technically their abstraction with the binary-build-system <KarlJoad>If a package shares the same name as a built-in Guile procedure, is renaming the package through a prefix when importing the best choice? <sneek>KarlJoad, you have 3 messages! <sneek>KarlJoad, rekado says: that’s because the package variable is called “ics-bind”, not “bind”. <sneek>KarlJoad, nckx says: *isc-bind <KarlJoad>rekado: nckx: That would explain the bind package name and bind Guile procedure conflicting. <jpoiret>sneek, later tell mothacehe: sorry for letting those pipewire errors through :( <vivien>KarlJoad, for make, the package is directly named gnu-make in its module. <KarlJoad>When byte-compiling shepherd services, during a guix system build, I end up with a lot of failures due to incompatible bytecode versions. Is this a known thing? This is not a breaking bug, the build and system still work, but a lot of failures get printed out. <KarlJoad>I also get ELF file does not have native word size. Both errors come from load-thunk-from-memory. <KarlJoad>lechner: That also worked for me. Strange that the manual does not really mention that format for specifying packages. <lechner>KarlJoad / i thought the same thing but once you have it, it's "out of sight, out of mind." <acrow>sneek: later tell vagrantc an improved version of debian-copyrighter.scm is available. <lfam>When it comes to creating Cuirass jobsets ("specifications"), is it feasible and desirable to write the manifest directly in the 'build' field of the specification, rather than creating a separate file in guix.git's 'etc/' directory? <lfam>I ask because it seems a bit icky to have short-lived manifests in 'etc/' <lfam>podiki[m]: No reason to keep it. It only went EOL a couple days ago ;) <nckx>Eh, I was literally about to ask the same thing about 4.9 (but saw it on IRC, not mail). <lfam>I loooove deleting this code <lfam>I think approximately 0 people use these old kernels in Guix <lfam>But let's change the subject to my question! <lfam>I just sent a message to guix-devel about a go-updates feature branch. Trying to find the best approach <nckx>Maybe an unpopular opinion but if really short-lived, why in guix.git at all? <lfam>I see there are some tests of the kernels. I will add a test for 6.1 <lfam>Right nckx. What's the right approach here? <lfam>I can try doing what I suggested, writing the specification in a verbose way <lfam>I'd prefer to have it written down somewhere, rather than using the web interface <nckx>I don't have any arguments against in-line. <nckx>lfam: On a more serious note, at least 2 people in the last month asked how to switch to 5.15 'for now' because 6 is still broken on their hardware. I'm sure many more quietly do. So your work's not in vain. <lfam>Interesting, I hope things start working for them <podiki[m]1>curious, was there a reason for the v4 kernels? I understand current and lts releases at least, was there some big hardware drop from 4->5? <lfam>No, the numbers don't mean anything <lfam>They got to 4.20, IIRC, and decided that .20 was enough <lfam>And, our tradition is to package all supported kernel series <podiki[m]1>nckx: I cheated and saw the message via Reddit, I'm not some cool person hanging out on the kernel mailing lists :) <podiki[m]1>lfam: so upstream has other versions besides mainline and lts that keep getting fixes? is there some concrete policy there? (just curious) <nckx>...there are cool people on the LKML? (Sorry.) <podiki[m]1>I leave it to the reader to decide if/any sarcasm :-P <nckx>It's an upstream policy, see kernel.org, we (mainly lfam :) just follow that. <lfam>We don't provide 'mainline' which really is like a technology preview that only kernel developers and experimenters use <lfam>This page that I linked it is what I treat as canonical <lfam>Torvalds releases mainline, then the 'stable' team creates stable and longterm releases <lfam>Yeah, another lexicon to master ;) <podiki[m]1>so longterm isn't just a single version, I had just assumed <nckx>For nginx, mainline means stable and stable (or whatever word they use) means LTS, consistency is really fun. <lfam>And people talk about getting their new hardware supported in "mainline". But, they really mean "upstream" <nckx>ACTION runs actual mainline, it's fun, you get actual oopses sometimes, do recommend. <KarlJoad>lechner: I added a paragraph and example to the manual because selecting an output the "lispy" way was non-obvious to me. <lfam>KarlJoad: Thanks! Do you have a link? <lfam>Oh, I see it in my mailbox! <paul_j>Evening all! Using emacs-next, how do I stop the warning buffer being filled up with formatting and coding warnings from included packages? Have I missed something when migrating to emacs-next from emacs? <paul_j>nevermind - seems I need to set native-comp-async-report-warnings-errors to nil <guix_noob>Hey Guix! I wanted to know, is there any recommendation/goo practice for managing emacs and its configuration using guix? should use a profile to manage and run emacs and its packages packages? Also I use (guix-emacs-autoload-packages), should I use or should I not use (require some-package) or (use-package some-package) since all packages <guix_noob>installed with guix are already loaded with (guix-emacs-autoload-packages)? Thanks in advance! <paul_j>guix_noob: Hopefully you will get someone more versed with guix than me answer your question shortly. What I would say based on my limited experience - I have emacs in my guix home configuration, and used the guix packages rather than melpa etc. I require them still, because I don't use guix-emacs-autoload-packages (I hadn't come across that). <paul_j>I reported issues here yesterday and the day before where I was getting an error message from guile: "Fatal Error: glibc detected an invalid stdio handle". After much disecting of my configuration, I have narrowed the problem down to having "set enable-keypad on" in my ~/.inputrc file. If I remove this one line, then guile works as expected without the error message. Should I report this as a bug, and if so, against guix or upstream? I <Euler-Maskerony>Hello. I am looking for a stable linux distribution as my main system and I really want to try guix, but I've read that it uses linux-libre. I have Intel wifi firmware and I have worries that fresh guix install won't have iwlwifi driver for it. Is that right? How can I resolve this? <lechner>Euler-Maskerony / Hi, there is #nonguix, if needed <lechner>sometimes, it is inconvenient to be consistent and true to a purpose <ieure> Euler-Maskerony, You're unlikely to get a reasonable answer here. Guix does not ship with iwlwifi, and if you install a machine with it, you will have no networking. The process to get it working is frowned upon, therefore not super well documented and fairly difficult (in my experience). You're better off exploring Guix in a VM, or using Guix as an alien package manager on a different distro. <tschilptschilp23>Hi guix! How would I find out which of the available linux-libre kernels is the current default one? The first result when asking 'guix show linux-libre'? <ieure>Euler-Maskerony, You will, at minimum, need to compile your own kernel, which takes hours and requires some kind of networking (like Ethernet) to accomplish. <paul_j>guix_noob: Thanks - I'll have a look at that <tschilptschilp23>lechner: perfect, thank you! I just was browsing with 'guix edit linux-libre' and got totally lost ;) <bdju>does anyone have the realthunder fork of freecad working on guix? I was thinking of learning freecad and it sounds like this fork has important changes that aren't all upstreamed yet <ecbrown>bdju: i will bet a million dollars that you are the guix expert on the topic ;-) <bdju>well the freecad package seems very up-to-date unlike some other packages so I thought maybe there are some heavy users of freecad around here <acrow>bdju: I'd be curious what you think of scad? It's in guix. I briefly used it and I liked the scriptability. Does freecad offer that? <bdju>I really don't know much about cad software. I've just been getting into 3d printing lately so I was going to explore my options. I was looking into openscad a little as well but it seems less popular for whatever reason <bdju>a friend of mine uses freecad (he is not on guix) and it works pretty well for him <ecbrown>bdju: it may be just as easy as modifying the existing package definition to use the modified version <ecbrown>i.e. change the url, and the sha256 and maybe it will build <ecbrown>other alternative is to find recent freecad commit and contact author <ecbrown>(in high likelihood the maintainer is not on irc) <bjc>my understanding is that a lot of the freethunder patches have been making their way into mainline as they can be vetted. and if you're new to freecad, i'm not sure how much of a real problem the topological naming system actually is <bjc>i've only been using freecad lightly for a few months, though, so ymmv <pmf>Does it still succeed if you remove --no-grafts from the invokation of guix shell? Similarly, does the build work if you pass --no-grafts to the invokation of guix build? <surpador>Tests succeed without --no-grafts for the guix shell; I just added it since the manual section on debugging uses it. Passing --no-grafts to the guix build command results in the check phase failing with the same message <surpador>I was thinking the message about changing user to 'nobody' could be a hint, but then the container doesn't seem to have a nobody user either and doesn't have the same problem <bdju>bjc: yeah, I'm not even entirely sure what topological naming is, I just figured better to start off on the right foot and not have to relearn stuff later if possible <rekado>efraim: I tried building up to java-testng with openjdk9 on aarch64, but I ended up having to build almost all packages with icedtea-8 anyway <rekado>I guess I’ll have to look at the output of “guix graph java-testng” to see if the world of java packages can be split into tiers <rekado>a limiting factor is the fact that we can’t use classes built with openjdk9 in a build that requires icedtea-8; this made me build many more packages than strictly necessary with the old JDK <haugh>anyone online familiar with (guix channels)? I' looking at read-channel-metadata and I have /a couple of questions/ <KarlJoad>How are people running mcron tasks weekly? mcron does not have a next-week procedure to use. Just using a lambda and some math? <drakonis>there most certainly is a week procedure <KarlJoad>drakonis: The checkout of mcron I just cloned does not have a next-week procedure. <KarlJoad>And checking out the commit that Guix uses (found with guix edit mcron) does not have a next-week or next-week-from procedure either. <KarlJoad>Although the documentation for mcron has indices and cross-references for it. <drakonis>perhaps it got removed in favour of just using next-day? <KarlJoad>A "git log | grep week" only shows one commit that uses the word "week", and that is about the Vixie side of things. <KarlJoad>haugh: Neither next-week-from nor next-week exist in mcron, despite documentation saying it does. <haugh>KarlJoad, how are you a) running mcron or b) searching its source? <haugh>this is relevant to my interests <KarlJoad>haugh: Running mcron? However Guix runs it. I am adding a simple-service to my services list to add a job. I am searching its source by cloning it and grep-ping ing. <haugh>and you were able to grep other functions from the (mcron job-specifier) module, such as range, next-hour, etc.? <KarlJoad>Yep. `mcron/src$ grep -nr "next-year" *` produces both next-year and next-year-from. <haugh>I guess use the vixie syntax? <KarlJoad>I'm just going to math it out for now. Perhaps a patch will appear in mcron for next-week eventually? <Maya[m]1>hi would something like the yuzu emulator be elegible to be included into upstream? <podiki[m]1>we do have other emulators, but it would depend on the license of yuzu at least <guix_noob>would be super duper interested in joining force to package yuzu and cemu! <guix_noob>from my experience those are a mess to compile from source though