<lispmacs[work]>if your source uses ./configure, that usually is enough, the build system can figure out where everything is based on those shell environment variables and package-config <nirnam>for this perticar case (dwm/st) it's just make and make intsall <nirnam>seemed like suckless software doesn't believed in configure <nirnam>well then, I do need to know how to modify the source before it being build, since it config files is in source code <maximed>Doesn't seem like patching the source code is necessary to allow the build to succeed is necessary, if that's what you mean <leoprikler>for more complex things see the patches field or aux-files <muradm>seatd/greetd services v3 is out, system tests included, few fixes and refactors <nirnam>I see, I was about to ask about how to patch source in guix package, because suckless thing usually doesn't function without patches <leoprikler>maximed: suckless tools "suck less" because they require you recompile the entire thing to make a tiny configuration change <nirnam>it wasn't a problems for >1 MB binary it is building to, I think suckless guy knows what they're making <leoprikler>i think typically you'd add it to your os packages, but other than that no <lispmacs[work]>nirnam: anyway, to answer your original question, `guix environment` exposing packages into your environment variables. This that you install normally get linked into a profile in ~/.guix-profile <lispmacs[work]>you can also make additional profiles if you don't want to pollute ~/.guix-profile with project dependencies <lispmacs[work]>nirnam: anyway, to answer your original question, `guix environment` exposes packages through your environment variables. On the other hand, things that you install normally with `guix install` get linked into a profile tree in ~/.guix-profile <nirnam>there's alot of change from my daily distro, this might not be the easy hop I hope it would be <nirnam>I'll play around with it in vm for abit, and problaby getting into troubles immediately, and I'll come around asking again <lispmacs[work]>it is a new paradigm, for sure, but a lot of features of guix are especially helpful for people who like to build things from source or modify things built from source, once you learn the basics <nirnam>funny stories actually, I love source base distro because it keeping me away from acutually building it myself <nirnam>portage been a help, put flags into makefile and valar thing are build exactly how I want it <lispmacs[work]>it is not something I do often personally, but as others have indicated, there are a lot of tools in Guix to modify existing packages on the fly - add flags, and what not <lispmacs[work]>but now I have switched all my desktop computers and service to Guix <nirnam>does it more ancient than ibm r51? I has one that was once ran netbsd <nirnam>I also concern about guix kernel, my hardware may or maynot using proprietary blob, how do I check whether or not guix kernel will work with my machine? <nirnam>I didn't burn the iso down yet, wanted to does thing in the vm first, I might just run some test on it with live mode <lispmacs[work]>since we don't have a live CD, I'm not sure how to test the drivers in advance. I suppose you could build linux-libre for your current distro and see if that works <nirnam>that is a good advice, if nothing break now this machine certainly will run guix <nirnam>it the license change for now I only have @FREE licence it will not allow none free package to install with out prompting me to add it <nirnam>altho I have linux-firmware with no-source-code license installed, that is alarming <char>Hello guix. any idea why I get $ ld -lpthreads <char>ld: cannot find -lpthreads <dstolfa>char: probably because it's -lpthread :) <lispmacs[work]>I think it must have something to do specifically with the way ld handles search directories <lispmacs[work]>LD(1) indicates that the default set of paths searched "depends on which emulation mode ld is using, and in some cases also on how it was configured" <pkill9>is there a way to load udev rules while booted? <pkill9>i just want to load some rules and test them without re configuring or anythign <char>lispmacs[work]: even with -L it cannot be found for me. <char>yes. I'm in an environment thought, so it is $GUIX_ENVIRONMENT/lib/*pthread* <lispmacs[work]>char: so, `ld -L $GUIX_ENVIRONMENT/lib -lpthread` does not work? <char>it does. it was that damn s after pthread <roptat>finally managed to fix the build of libziparchive (a dependency of fastboot) at the latest version! That soong-build-system is starting to look good :) <iskarian>What's the policy for grouping changes into one commit when, for example, changing a package name, or making an input propagated and then removing it from a downstream package? Should they still be split, or kept in one commit so that all commits work? <lfam>Make all commits work in that case, iskarian <lfam>So, for your example, one commit <Fare>Has anyone here got CUPS working? Trying to enable the web interface with cupsctl WebInterface=yes I get an internal server error :-( <Fare>Aha, I had to both change my guix-config AND manually restart the cups server. <Fare>... but the admin page is now blank instead of an error message! <Fare>couldn't get the web admin interface to work, but I learned how to use lpadmin <Fare>but something is still not working :-( <Fare>OK, so with lpadmin and lp://ip.number I could connect to it, but apparently I did the PPD or something wrong. <Fare>(Just trying to reuse the PPD that was working on NixOS) <char>lispmacs[work]: if libpthread.so is already available in LIBRARY_PATH then why does ld require -L to the same location? <char>dstolfa: the reason I had pthreads instead of pthread is because the error message I get is "ld: cannot find -lpthreads", but it cmake, and I can't figure out where it is comming from ***kulernil is now known as kuler
<Fare>"If you can read this, you are using the wrong driver for your printer." <kitzman>is there a way to specify multiple source files in "source"? i'm thinking that the only way to achieve this is by creating a snippet in the origin. <leoprikler>"multiple source files" as in several files or as in several origins? <kitzman>(by creating a snippet i would i would curl it?) <kitzman>if that doesn't work i guess the only solution would be defining a package which only contains the desired file, then add it as input to the main package <abrenon>yoctocell: thanks a lot for your detailed review <abrenon>indeed "where to look for packages" is rather clumsy <abrenon>I think we can do better than "used to lookup", what about "repositories which will be searched for packages" ? <maximed>sneek: later tell kitzman: You can use 'file-union' to combine multiple directory structures <yoctocell>abrenon: yw, "repositories which will be searched for packages" does sound better :) <abrenon>thanks ! I wanted to avoid submitting yet another version of my patch before settling this <maximed>sneek: later tell kitzman: Or cobble something together with 'gexp->derivation', #$output, etc <abrenon>I'll send it with this formulation, along answers to your remarks <iskarian>kitzman, you can also use a straight (source ...) as an input, but you'll have to unpack it yourself <maximed>iskarian: actually (package [...] (inputs `(("something" . ,(origin ...))))) ('source' is a field of 'package', 'origin'/<origin> is a constructor/type <maximed>tbf, 'origin' and 'source' are almost always used together <iskarian>Aha! I think I've cracked getting Go to reuse .a files! <iskarian>It takes about as much time to unpack and patch as it does to build, now... tests are an order of magnitude longer than actually building, now <abrenon>there's so much to answer ! and writing it makes me realise things I should've written in the documentation <mjsb>Good morning Guixers! I was wondering, which would be an easy way to install kubectl and awscli2.0 (guix's at version 1.8) on a guix system ? <kitzman>thanks all for the replies, using the origin as a native-input works pretty well. <sneek>kitzman, you have 2 messages! <sneek>kitzman, maximed says: You can use 'file-union' to combine multiple directory structures <sneek>kitzman, maximed says: Or cobble something together with 'gexp->derivation', #$output, etc <maximed>mjsb: Maybe updating 'awscli' to 2.0 is merely matter of running "guix refresh -e awscli python-botocore" <maximed>or maybe there are some complications <mjsb>maximed: i'll try that! Thanks for the advice! <pkill9>it's a nice feeling when you want to build some piece of software that was finnicky, then you find you made an almost complete package definition ages ago for it and it just needs some wrapping to complete it <pkill9>in this case it's sc-controller, a configuration gui for the steam controller <pkill9>which is a much nicer controller than i thought back when i got it <pkill9>and i got it on sale for 5 quid plus 8 quid shipping when it was discontinued <pkill9>thanks for coming to my TED talk, please clap <efraim>guile-3.0.2 might be too old for core-updates-frozen <Rohit>Is this official gnu guix channel? <sneek>Welcome back Rohit, you have 1 message! <sneek>Rohit, nckx says: You can always *try* to request a package :) Very rarely, it even works. However, micro-editor is written in ‘Go’, a low-quality language that makes packaging zero fun, so its chances of being packaged are slim. <dstolfa>i do wonder where nckx is... i miss them :( <Rohit>Does Guix have a unstable branch like Nix have unstable branch? <dstolfa>leoprikler: ah, irc and its pinging whenever a name is mentioned... :) <dstolfa>Rohit: well, guix is a rolling release to begin with, so even the master branch is unstable in that sense (kernels change and so on). however, there are some policies around upgrading packages that many other packages depend on, and that usually happens in other branches (see core-updates, various wip branches and so on) <Rohit>Why some packages like gnome are so old, and is there a way to update them to latest version? <dstolfa>i'm sure they would appreciate testing <raghavgururajan>Hmm, font-dejavu is getting propagated somewhere, but not sure where. <leoprikler>raghavgururajan: the gnome package itself propagates font-dejavu <roptat>I made a few steps towards packaging the newest adb/fastboot yesterday :) <roptat>still a few packages missing before I can package adb/fastboot, but it's getting there, the soong-build-system needed a few fixes yesterday, I hope it'll go well for the rest of them :) <roptat>I'll work on that this week-end, hopefully I can find out how to build a cc_object, and then I should be able to import the missing packages :) <yoctocell>abrenon: just commented on your revised opam patch :-) <yoctocell>thanks for the explanation regarding the "janestreet re-versionning" <abrenon>I'm not sure it's janestreet packages only, but it looks like they initiated this new style of versions ? or something ? <abrenon>not sure, I don't know much about it myself, I just tried to keep the logic I found when starting to work on it <yoctocell>but is it common for a package to go from using no prefix to using the "v" prefix? <abrenon>I don't understand your last remark about the missing comma <abrenon>is that a syntax rule of english ? I noticed I tended to do this often: separate the "and" conjunction from what's before with a comma, but I got criticized several times for doing this in my natice language, french <abrenon>I then learnt to restrain from doing so and thought it was the same in english <yoctocell>I am not a native speaker, but I found it little bit hard to following the last sentence <yoctocell>like "a, b and c" would separate "a" and "b and c", whereas "a, b, and c" would separate "a", "b", and "c" <abrenon>no, that's the "oxford comma", but there's no such ambiguity here <abrenon>because we're outside of any enumeration <abrenon>granted, it could group with "others", but that is then disproved by the later occurrence of "will" that prevents from parsing the sentence in that case <abrenon>I agree with you, it's much more readable with the comma, but the way you put it made me fear I had broken a syntax rule I ignored, and I wanted to make sure it was only a matter of personal taste <yoctocell>yeah, I was a little terse, sorry about that <abrenon>no, no, not at all ! I'm just a bit insecure with english at times <yoctocell>I think it it's better to be a little more explicit in this case :) <abrenon>I don't agree with the s/must/should/ though <abrenon>if the user wants the importer to behave like she wants, she *has to* pass the repositories in her preference order <abrenon>I hesitated with "Repositories are assumed to be", to express that no matter what the user prefers this is the way the importer will work with what it receives <yoctocell>hmm, I felt like "must" sounded a bit too strong, but it's probably the right word in this case <abrenon>don't you prefer the idea of assumption made ? <yoctocell>not sure what you mean exactly with "Repositories are assumed to be" <yoctocell>you mean that you would write that instead of something else? <abrenon>yeah, sorry ^^ the "must/should" § would instead go : "Repositories are assumed to be passed to this option by order of preference." ***apteryx_ is now known as apteryx
<abrenon>was my first intent, then I tried to simplify ^^ glad you like it better, I'll put it back and keep the rest of the § like you suggested <abrenon>collaborating on documentation is such hard work ! but the result is so much higher quality than anyone alone would have achieved. Thank you for your feedback <yoctocell>yeah, agree, getting someone else to your stuff helps a lot! <efraim>pcre2 FTBFS on core-updates-frozen on powerpc-linux <efraim>segfault in a JIT test, might not actually be supported <efraim>it's also not supported on riscv64-linux, so I guess I shouldn't be too suprised <efraim>well that's worth another look, debian has JIT enabled for ppc in 10.36. Maybe it did break for 10.37 <yoctocell>abrenon: the updated patch looks good to me, but I don't have commit access, so someone else will have to merge it <abrenon>yeahhh \o/ thanks again for your help <abrenon>now, I still have to use the new version of the importer to package the package I needed in the first place ^^ <Fare>OMG, I still can't print anything. It was a huge pain getting the right PPD on NixOS, which I managed to do... twice, as CUPS at one point started rejecting the PPD I crafted. Upgrading to Nix, and neither of the previous PPDs work. WTF? <roptat>abrenon, thanks for all you did! I'll push the new importer this evening when I get home :) <abrenon>you mean you think it's ready ? that's great news !! <Fare>Aha, on NixOS, my current setup involves some special filter program from Brother. Sigh. <rekado_>I’m using brlaser with my Brother printer. Works fine. <Fare>rekado_, does not look like it's working for me. What printer do you have, with which driver? <Fare>(I have a MFC9970CDW. I once crafted a PPD with no filters, it used to work fine. Then stopped when I upgraded cups, so instead I used the mfcl8960cdwcupswrapper on NixOS, which uses a 32-bit binary wrapper from Brother. <Fare>Now I'm trying on Guix. The old PPD still doesn't work, but the binary wrapper isn't in guix, and I don't know what to do. If I understood what made cups stop working with the unfiltered thing, I'd fix it. <Fare>It could be something very very stupid like it used to have a trivial header or footer that is now not included, or vice versa. <roptat>abrenon, mh, if you don't think it's ready, I'll read it once more and try it, but I didn't have any more comments on that patch <roptat>is there anything I should pay close attention to? <abrenon>no, nothing particular, it's just it was a long process and there always seemed to be something else to improve, so now I'm worried we might have overlooked something ^^ <abrenon>the only major thing you haven't seen so far is the removal of the "redundant" warning <abrenon>actually, explaining the behaviour of my changes to yoctocell made me realize it wasn't redundant ! <roptat>ok, I'll let you submit a new version then :) <lispmacs[work]>char: I think that ld must not use $LIBRARY_PATH. LD(1) manual page does not make it clear <lispmacs[work]>LD(1) says that the paths searched are based on the "emulation", whatever that means <roptat>mh? I thought you meant to change something because it did not do what you thought it did? <abrenon>no, no, I was talking about what happened when I was writing my long answer to yoctocell about 6~7 hours ago <abrenon>but the version I sent then contained that edit <abrenon>I just mentioned it to be sure you were fully aware that there was no mention of --repo=opam being redundant anymore <abrenon>since it was a thing we had discussed <roptat>then I'll read the patch again, give some feedback if I have any or push :) <ruffni>i'm installing guix on a rockpro64 (yay). but it compiles linux-libre, and (i guess) pretty much everything (which takes quite some time). am i doing it wrong? is ARM64!=aarch64? are there no substitutes (though cuirass shows 100% coverage for aarch64 on channel guix)? <cbaines>on ci.guix.gnu.org, it's the master specification that builds packages I believe <cbaines>the substitute availability is actually quite high, 60.6% for the revision I checked <cbaines>bordeaux.guix.gnu.org has 85.1% substitute availability though, so it's more likely to have built the things you want <ruffni>thanks for clarification! now, that's a red image! not sure i really get it, though. WDYM with "master specification that builds packages"? would i have to do anything special to get substitutes from bordeaux? i installed guix (on debian host), did a `guix pull` and now a `guix system reconfigure config.scm` <podiki[m]>has anyone here used an u2f key with icecat? it is failing (e.g. github login, or u2f demo sites). I think it needs raw access to hidraw, maybe that's why? <ruffni>is it working apart from icecat? <ruffni>i had to add pcscd-service to my system configuration, but now my librem-key works like a charm :) not sure if that's related (or even the same kind of thingy) <ruffni>cbaines: how recent should guix be? is 1.3.something enough or like *really* up to date? and is it possible to add the substitute key before system installation? bordeaux should be among the default substitutes (if i understand the manual correctly) <cbaines>otherwise, you can add the URL explicitly <ruffni>yes, i saw that option -- but this left the question on how to add the key :) <cbaines>if you're on a foreign distro, use guix archive to add to the ACL <cbaines>if you're using Guix as a system, you probably want to edit your config <ruffni>might be a good thing to link that part of the docs to the welcome-page on bordeaux.guix.gnu.org <maximed>On Guix System, bordeaux is in %default-authorized-guix-keys <podiki[m]>ruffni: yes the key works as a smartcard for gpg etc.; just the u2f in browsers not working <podiki[m]>I'm guessing it is not getting hardware access, but throws no useful errors or anything <podiki[m]>bricewge: that was your patch? should u2f be working in icecat? <bricewge>When I submited the patch I tried it in icecat and it worked well <bricewge>I thought I mentioned it in the patch, but no <podiki[m]>I don't see eudev in the current icecat package definition, or am I missing it <podiki[m]>does it need pam-u2f or something installed? I think I just have the pcsc service <bricewge>Indeed it doesn't works with /gnu/store/gq7g2ryazgmcrqcj0fh4vjfsy0zcy1d0-icecat-78.12.0-guix0-preview1 <bricewge>I'm using this service `(udev-rules-service 'u2f libu2f-host #:groups '("plugdev"))` with my user as a member of plugdev group <podiki[m]>yeah, not seeing that commit on guix master, just the icedove part...lost in the shuffle? <bricewge>I have a v3 of the patch locally, with some comments about succesfull testing on yubikey's test site, but It never made it into the ML <bricewge>I'll build it again, test it, and then push, it will take some time <podiki[m]>I love finding that a patch already exists for what I want fixed, even better when it gets pushed so quickly :-) <podiki[m]>I'm like 95% to having my full system set up just like how I had it in Arch <bricewge>All bugs related to pcscd/webauthn/u2f are fixed ATM, so feel free to reopen one if you have find an issue about that <podiki[m]>I need to build a few packages, which I don't anticipate trouble with <podiki[m]>one is autokey, a python key mapper that so far I found was the best way for more universal emacs keybindings <podiki[m]>need to set up a periodic trim for my nvme (looks like just a few lines with mcron) <podiki[m]>rofi-calc should be another quick one, very handy for math, conversions, from rofi <bricewge>Nice, nothing insurmountable to package. I would use rofi-calc. <dstolfa>podiki[m]: no matter the calculator setup i have on my computer, i always end up using like 10 of them anyway <podiki[m]>rofi-calc uses qaculate which I find does everything <podiki[m]>and since I like rofi/dmenu, it is easy go to <podiki[m]>I have shortcuts to run rofi as: launcher, calculator, oath codes, password access; quick and easy <dstolfa>podiki[m]: oh i'm not trying to imply that it doesn't, it's just that i tend to use 10 different calculators based on what i have open, e.g. a web browser, a terminal, emacs, a repl, etc :P <podiki[m]>I use emacs calc plenty too, but in embarrassingly simple ways (really need to learn). or sometimes the scratch buffer for some lisp calculate <podiki[m]>question: what is a quick way to know in a script (or a .bashrc or .zshrc) if the system is guixsd? <lispmacs[work]>podiki[m]: I'm not sure, but I'm curious what `guix system describe` returns on a foreign distro <podiki[m]>maybe can just check for something in a typical FHS path? <podiki[m]>I can do this based on machine name (it is for my configs), but thought it would be nice for a more general check <Fare>Maybe I should try with gutenprint. I don't see it in guix yet, though <dstolfa>lispmacs[work]: `guix system describe` will simply report that there are no generations (and currently give you a backtrace?) <muradm>i realized that there was mistake in last update to 49969, 3/10 has no v3 tag in subject <Fare>Ahem... OK, so I've hacked nixpkgs and used guix. How do I learn to hack guix? <dongcarl>If anything seems updated I'd search through the man manual <muradm>i have similar question actually, i have guix system on my laptop, now i have separately cloned and compiled source code of guix, pre-inst-env works, i wander if i can do "guix system reconfigure"? <dongcarl>That I don't know since I don't use guix system <muradm>to reconfigure my system not with "guix pull && guix system reconfigure" but "cd ~/devel/guix && git pull && guix system reconfigure" or something like that <bricewge>muradm: Yes, you can reconfigure form pre-inst-env <muradm>bricewge: so it will apply to my system? any precautions? <muradm>will it pick the ~/.config/guix/channels.scm as well? <bricewge>Unfortunately I never manage to submit and upstream all my patch, always have ~50 commit on top of master <bricewge>If you reconfigure you anly change your system configuration not guix the package manager <bricewge>But if you "guix pull" from pre-inst-env, you would want to configure with "./configure --localstatedir=/var --sysconfdir=/etc" or /etc/guix.acl won't be handled correctly <bricewge>muradm: As for #49969, I would have wanted it to use the standard "pam-mount" service instead of "seatd-pam-mount" pacjage <muradm>stat of /etc/guix.acl failed: No such file or directory? <muradm>bricewge: why do you need exactly pam-mount? <bricewge>But I gueess using (and patching) pam-mount correctly could be done after the fact <muradm>the problem with current pam-mount package and pam-mount-services-type is that it is not very extensible <bricewge>I don't need it per se but having a specific package, with some copied and paste config to make the rules, isn't really elegant <muradm>pam-mount can do many mount types for instance, but pam-mount-service-type is preconfigured to do mainly cryptmount <muradm>and you can have only one pam-mount-service-type <muradm>so if some user already uses pam-mount-service-type for his purpose, greetd service won't be able to use pam-mount in any way, either inject necessary configuration or else <bricewge>Indeed it isn't extendable at all, that feature need to be added to pam-mount-service-type <muradm>bricewge: it will require a lot of engineering to merge xml configurations in the way that they are not conflicting with each other <muradm>pam_mount.conf.xml can have mutually incompatible ways of configuration <muradm>as far as i digged pam_mount source, i could not figure out a way that it could be configured declaratively in multiple places and merged in pam-mount-service-type <muradm>another issue with pam_mount was comming from mount/unmount ref counts <muradm>in my first attempt i was providing XDG_SESSION_ID variable based on pmvarrun ref count <bricewge>podiki: I've pushed bccfcef473da6d91f2c2cd444227721013570918 which adds webauthn support to icecat, I tested sucessfully on yubikey's test website <muradm>having using pam-mmount for multiple purposes just screws things up <muradm>best way would be of course to improve first pam-mount it self by adding at least: a) configurable config path b) configuration run time data c) context in which this config is running <podiki[m]>thanks bricewge, I'll take a look when I get the updated package later <muradm>then pam-mount-service-type can be done easily configurable, just use pam_mount.so multiple times with different configuration <muradm>however reality is that everything is hardcoded in pam-mount it self <muradm>trying to workaround this, will require separate ai to merge declarative independent configurations in one pam_mount.conf.xml <bricewge>Just glancing over that part of your patchset and pam-mount-default-configuration, you mostly added a volume. <muradm>also pam-mount-service-type pulls crypt dependencies which are not needed in any way by greetd <bricewge>Anyway, I don't think showstopper as long as we can fix it later and we can make this change be retrocompatible <muradm>practically it is not workable i think as far as i digged pam-mount <muradm>bricewge: yes, goal was to make user unaware of pam-mount configuration by greetd <bricewge>I'll try to test your patch set during the weekend if I can find the time <muradm>so it is hidden, and in the future can be replaced with something else different <muradm>i was thinking about something like pam-xdg.so <muradm>which will do what pam_systemd.so but only very minimal necessary stuff to provide xdg environment <muradm>bricewge: there is a test case in gnu/tests/desktop.scm in last update :) <muradm>should be helpful to make things clear on what greetd/seatd does <muradm>i think all this work will be usefull in next release of sway when they drop (e)logind support <muradm>another thing i think is that technically/logically greetd should be in gnu/services/base.scm and seatd might be in gnu/services/desktop.scm <muradm>currently both are in gnu/services/desktop.scm <muradm>another thing to note, is that i also implemented a graphical login with greetd <muradm>but i'm not very satisfied on how it works in general at the moment <muradm>so i decided to keep only terminal greeter at the moment, once this seatd/greetd will make to guix, we can add other greeters incrementaly including tuigreeter (which prompts interactivelly what to run), graphical greeter <muradm>i just sent 03/10 again with fixed subject line, just in case ***lukedashjr is now known as luke-jr