<bandali>submitted a couple emacs packages from my personal channel to guix-patches@; all feedback welcome and appreciated :-) ***jonsger1 is now known as jonsger
<Gooberpatrol66>is there a way to get "go to definition" in guile without using emacs? <roptat>For guije I don't know, but guix has guix edit which is able to open the source file at the right location <roptat>Maybe the implementation could help you find something useful for what you want to do? <bandali>anyone familiar with package-with-explicit-python from (guix build-system python)? <bandali>i’m kind of confused about its use/need for variant-property <drakonis>the migration to guile 3.0 broke the website <drakonis>clicking on a package and then package sources leads to a path in the store rather than a path in the repository <bandali>Gooberpatrol66, i just use good old grep for that <zzappie>Is anywone having emacs-new throwing backtrace when edidting scheme files? <DamienCassou>I installed guix on Fedora. All commands complain that the locale en_US.UTF8 is missing. Should I install a package? <g_bor[m]>is there an easy way to find out the amount of ram programmatically? <g_bor[m]>I would like to tune a service config to it. <g_bor[m]>I guess I can read /proc/meminfo, or do something like that along these lines, but if there is something already available that would be great. <zzappie>hey g_bor[m]! I only know of "free" command <zzappie>DamienCassou: Try installing glibc-locale <bricewge>g_bor: I don't think so. Shepherd would have to support cgroup to achieve something like systemd.resource-control. <DamienCassou>zzappie: I'm trying, thank you. Isn't it weird that this is not installed by guix-install.sh? Should I report that as a bug? <g_bor[m]>liberdiko: I came up with a solution reading /proc/meminfo finally. <zzappie>DamienCassou: I dont know there is probably a reason why it is not installed. Probabbly because it is weights arround 100 mb <g_bor[m]>what do I need to require to have the system packages available in a service? <zzappie>DamienCassou: strange. I had same issue with for a while on debian. But it dissapeard one day <g_bor[m]>I suspect I miss something, as it works on reconfgigure, but not on boot <zzappie>DamienCassou: Maby guix pull and guix package -u ? <g_bor[m]>Damien Cassou: this usually indicates a daemon guix pulled guix glibc version mismatch. <g_bor[m]>What helped for me is the following: 1. pull as user, install locales as user. pull as root, install locales as root, fix the service file to point to the new daemon, restart the service. <g_bor[m]>also make sure that the GUIX_LOCPATH is set for both the daemon and for the user to the correct value. <g_bor[m]>actually I am on Guix System for a while, but last time I did this on debian this worked. <DamienCassou>I'm starting to worry a bit about Guix. My plan was to experiment a bit on Fedora before switching. But I'm facing many problems. I hope Guix System has less issues <zzappie>DamienCassou: the good news is you can experiment with guix without woryig about screwing up your system <g_bor[m]>I have a confgi with opensmtp and postgresql. It was working for a while, but now suddenly all files in /var/lib/postgres got chowned to smtpd:smtpq, and postgres no longer starts, unable to accessing its files... <efraim>i'd assume something with the activation scripts. does opensmtp use postgres? <g_bor[m]>I asssume it might be related to that I had to roll-back my system-config several generations, and the accounts are regenerated in a different order after reconfiguring. Is that possible? <civodul>efraim: congrats on the guix.vim release! <efraim>it's actually my first time doing anything like that <civodul>heh, good, there's always a first time <g_bor[m]>:) actually it worked for the second reconfigure... <civodul>efraim: BTW, if there's more Vim advice you'd like to put under "Formatting Code" for example, please share <g_bor[m]>nope, false. it did not work for the second time, it's just it did not tell that it failed. <civodul>g_bor[m]: when you switch to a system that has (say) the "smtpd" user, and then back to one that doesn't have it, and then back again to one that does have this user... <civodul>then the odds are that the second time you won't get the same UID <g_bor[m]>civodul: yes, that was what I suspected. <civodul>see commit a43e9157ef479e94c19951cc9d228cf153bf78ee <civodul>thinking about it, and having watched the systemd-homed talk, i think we should unconditionally chown-R user homes when needed <g_bor[m]>civodul: yes, that would be one way to get around it. <g_bor[m]>I think I will now just add an ad-hoc service, and prepare a similar patch for postgresql later. <g_bor[m]>also, in this case the directory itself has the right owner, but the files inside don't <efraim>I might edit Formatting Code later. Right now there's no difference with indentation using guix.vim. I'll have to see about converting etc/indent_code.el to vimscript <efraim>*no difference compared to not using it <g_bor[m]>ok, there is only a slight modification needed for the postgresql activation. <g_bor[m]>also, the directory has the good permissions only because it is explicitly set in the activation. <efraim>does anyone have a local-file snippet for a git repo that either honors .gitignore or ignores the .git folder? <civodul>g_bor[m]: i think it's worth raising the general case on the ML at least <civodul>so you think the output of ";;guix pin" got removed somehow? <jboy>civodul: It seems like it. Or actually, it may just be that the github renderer fails to show the html. <jboy>civodul: Just checked, it's in the notebook after all. Never mind. <civodul>anyway do let me know if you have feedback about Guix-Jupyter <g_bor[m]>civodul: where should I look for this code? user-home service? <civodul>g_bor[m]: i'd do that in (gnu build activation), with an approach similar to that used for gdm <civodul>that is: recurse only if the home dir itself has a uid/gid mismatch <civodul>and only for home dirs not shared among different accounts (like /var/empty) <shtwzrd>is `guix pull` broken right now or is it just me? I've tried to pull the last few days but it always hangs on guix-system.drv. Seems to fail in ice-9/boot-9.scm <civodul>shtwzrd: could you paste what you got? <pkill9>is there a TUI irc client that's simpler to configure than weechat? <pkill9>or maybe a weechat plugin that makes configuration simpler <civodul>rekado_, nckx: did you see the balance data from the FSF? WDYT? <shtwzrd>I'm currently re-running it with higher verbosity to see if it gets any more informative. I'm on a foreign install (Debian) and on aarch64 if that has any bearing. :) <civodul>unfortunately there's no solution yet :-/ <civodul>it's not deterministic, so it might work if you retry <pkill9>idea: weechat-plugin-build-system <pkill9>just to wrap the weechat plugins with their requirements <kmicu>pkill9: what should be simpler? <pkill9>oh actually the weechat package definition adds the main dependencies for plugins <pkill9>kmicu: i was just thinking of plugins that require python libraries <shtwzrd>civodul: aha! Yes this sounds like my issue. I'm re-running now and will see if my stack looks similar, but this seems likely. I'll keep trying to re-run it, not using this machine for anything else atm. Thanks for your help :) <pkill9>weechat itself calls the interpreter though, so wrapping the plugins themselves wouldn't work anyways <civodul>shtwzrd: yeah, i'm sorry for the breakage <kmicu>pkill9: Heh, you could start using glirc and write everything in Lua and Haskell tho not sure that fits your definition of simpler 😺 <kmicu>(Or use basic features of weechat and configure the rest in weechat.el so elisp x) <pkill9>what's weechat.el? emacs interface for weechat? <kmicu>Yep. We can use Emacs and its ecosystem as shell to weechat so a lot of weechat plugins are no longer necessary. <zzappie>hey did guix just jumped to guile 3? <nckx>zzappie: It did. The pulled version, at least, last I knew the ‘guix’ package hadn't yet. <nckx>civodul: Reading mail now 🙂 <zzappie>civodul: ah i see realized it when got "incompatible bytecode kind" in repl <civodul>zzappie: ah yes, not a great way to learn about it ;-) <civodul>did you see "guix pull" news though? <nckx>civodul: I'm looking at the spreadsheet now. Should anything have caught my attn.? <nckx>(Would be nice to do without the ‘management fee’ but as long as that 10% is going back to the FSF, not their bank, I don't mind as much.) <civodul>nckx: like i wrote, the dates in the future and also lack of info prior to Oct. 2019 <nckx>civodul: Missed that message. Since they're blank I read the future dates as boilerplate ‘fill this in as we go’, or some idiosyncracy of their export software? It's not like we're signing off on the 30/09 number. The missing prior info is a bit unhelpful but, well, I don't really know how the FSF usually does this. I can always ask for more info if you want, you're probably busy packing. <nckx>To give them the benefit of the doubt: you asked for ‘an overview of our bucket’ which leaves a lot of room for interpretation. <civodul>nckx: right, initially i just wanted the current balance <nckx>civodul: Did you see the ‘FY2019’ tab? <civodul>nckx: would you have time to start an Org file with things to discuss for the state of the union? <nckx>Eh, I was going to ask you what that means to you. <nckx>Sent you a msg last week(?) but guess it got lost. <nckx>I don't have time but I'll make some. Just not to learn Org. <shtwzrd>I could try running it some more, see if it actually dies in the same spot for me *nckx means /msg, not mail. <civodul>shtwzrd: this stack trace looks like another bug... *jonsger sent a nckx ish patch in :P *nckx braces for whatever the hell that means. <shtwzrd>also second run with --debug=2 just completed, got an identical stack-trace so at least it seems to be consistent :) <nckx>jonsger: Well, yeah, what's wrong with that? 😛 Kind of sad that's what you call it; I do hope to write (much) more actual code this spring. <jonsger>nckx: I honour your work and find it very important. It makes guix search/show valuable and often even better then Google/DDG <nckx>jonsger: No worries 🙂 's Just my own frustration at the state of my contributions. My two current jobs (skiing & motorcycling instructor), as rad as they are, combine extremely badly with the quick-package-while-nobody's-looking lyfestyle & I miss that. <nckx>So here I am fixing home pages & helping folks on IRC during meals. <jonsger>nckx: I do start packaging a lot of stuff, but finishing (bringing upstream) only a fraction of them :( <zimoun>Hi, using 'cmake-build-system' how can I remove the (default) flag -Werror? or at least -Wconversion which seems the culprit? <nckx>zimoun: [untested] Try adding -Wno-error (or no-conversion) to -DCMAKE_C{,XX}_FLAGS= in #:configure-flags. <nckx>I'm not sure what the semantics are, whether it appends or replaces the default CFLAGS. ***ng0_ is now known as ng0
<zimoun>Unrelated, but trying to debug, "guix build -L my/suff my-pkg -K" fails and then "guix environment --container -L my/stuff my-pgk" and "cd /tmp/guix-build-blabla" and the usual "cmake ../source/" success. And one main difference is the flag: build uses -I/gnu/store/...-depends-1.67/include and environment uses -isystem/gnu/store/...-profile/include (pointing to the same store item than -I). I was expected exactly the same thing... Well, <zimoun>is it expected or am I doing something wrong? <bavier>zimoun: -i declares a "system include" which is searched prior to other include directories <bavier>this can make a difference if a header of the same name is present in multiple places in the search path <bavier>and may affect the preprocessor macros defined for later headers <nckx>Yep. I wonder why the flags differ between environments, though, but then I never debug builds that way 🤷 <zimoun>nckx: #:configure-flags '("-DCMAKE_CXX_FLAGS=-Wno-error") seems to prepend and there is not effect. I have not found the rule in 'man gcc' when -W and -Wno- is given in the same time. Probably -W wins. <zimoun>bavier: thank you for the explanations. <nckx>I think it's just flag order (last one wins), but I'm not certain. *civodul shamelessly borrows from the illustrations rekado_ made last year <nckx>Of course things might get ‘interesting’ when you combine general (-Werror) and more specific (-Wno-foo-error) ones. <zimoun>nckx: I never debug builds that way neither. But I do not understand why "guix build" fails. I thought it was about -Wconversion (turned on error with -Werror) but then inside "guix environment --container" compiling does no fail, so I was just asking myself why? <nckx>Ah, fun 🙂 Does the build print the full command lines? Is -isystem really the only difference? If you're really stuck, paste a link to the full ‘guix build’ log here or send it to help-guix@. <cschorn>how do i change config files in a per user environment? I am trying to use local apache/php on ubuntu for development <lispmacs[work]>I remember reading a while back about some kind of package that allowed you to turn multi-step processes into guix packages. I was interested in that again but can't remember the name of the project... <cbaines>lispmacs[work], maybe the Guix Workflow Language? <lfam>I'm struggling with loading shared libraries of xmlsec-nss. <lfam>If I do `./xmlsec1 --encrypt --crypto nss test` it fails to find the library, printing "Error: unable to load xmlsec-nss library... [more about LD_LIBRARY_PATH]" <lfam>When I set LD_LIBRARY_PATH, it works <lfam>However, the RUNPATH of libxmlsec-nss.so does include the same path as the one that works with LD_LIBRARY_PATH <lfam>And when I strace it, I see that it is not looking anywhere in RUNPATH for this library <lfam>It just looks in the "standard" locations like /lib, /usr/lib, and the lib/ directories of glibc and gcc <lfam>Is there something in how xmlsec is built that instructs it to ignore RUNPATH? <civodul>lfam: how did you build that xml-sec1 binary? <lfam>It's the one from Guix civodul <zimoun>bavier, nckx: I have solved the issue and finally I did what I did not want... open the CMakeFile os the package. So, the CMakeFile owns an option to turn off the option, i.e., remove -Werror of the flag. Well, the problem with myself is not solved... I do not understand something, but the package builds. Thank you for the help. <lfam>Specifically the xmlsec-nss package, but I have the same issue with the default xmlsec package, using gnutls, as well as a private xmlsec-openssl package <bavier>zimoun: sometimes digging in is all that can be done. Glad it works, the rest can be figured out some other time <lfam>Now I'm reading the build log of xmlsec-nss, but I'm grasping at straws because I don't know in what cases the executable would ignore RUNPATH <lfam>The other thing is that while searching for things like "xmlsec runpath" I find a few bug reports on the subject filed with the xmlsec project, and the maintainer there just posts a link about how shared libraries work <lfam>So, not much help upstream <lfam>Not sure if it's relevant but I'm going to try adding those linker flags <civodul>lfam: this message from libtool can be ignored <lfam>Yes, adding the linker flags (again?) didn't help <civodul>BTW, you mention LD_LIBRARY_PATH, you should really try with LD_LIBRARY_PATH unset <lfam>Normally it's not set at all <lfam>I only set it while debugging to see if it helped and it did <lfam>The problem case does not have LD_LIBRARY_PATH set afaict <lfam>Hm, I suppose I didn't check if it was set but empty <civodul>lfam: one thing you could try is LD_DEBUG=files *civodul rushes back home <lfam>I tried that and it finds the library <lfam>The xmlsec1 package provided by Debian works okay here <A[m]3>do you use org-drill for Emacs in Guix? <A[m]3>is it part of emacs-org-contrib package? <smithras>A[m]3: Funny story, I was just trying to install org-drill this week <smithras>It got removed from the emacs-org-contrib package a few months ago, on the rationale that it is available as a seperate melpa package <smithras>but that separate package is not in guix yet <smithras>I made a local patch last week but I've been to distracted to submit it to guix, thanks for the reminder <smithras>A[m]3: oh just kidding it's in the latest guix revision! Someone beat me to it :) <smithras>A[m]3: wait sorry, I'm mistaken, it's not in guix yet <smithras>I just ran 'guix search' without realizing that it can search my local channels too <bavier>anyone have luck setting up a bridge network with our virt-manager package? <bavier>Seems to me like qemu-bridge-helper would need to be added to setuid-binaries? <A[m]3>> It got removed from the emacs-org-contrib package a few months ago, on the rationale that it is available as a seperate melpa package <smithras>A[m]3: Yeah, I guess once upon a time it made sense to bundle lots of small programs together with org mode, and now melpa is the preferred way to distribute them <A[m]3>> I made a local patch last week but I've been to distracted to submit it to guix, thanks for the reminder <A[m]3>how long it will take to spread from local to global channel? <smithras>A[m]3: You've inspired me to try and submit the patch tonight! Assuming I get that done and there aren't problems with the patch then it'll probably be pushed within 24 hours <smithras>If you need it right now I can give a link to my channel <lfam>Looks like a loooot of distros have the issue I am having <A[m]3>no, 24h is not so long I think. <A[m]3>I tried to package one Qt app when I had a little time on New Year holidays but failed unfortunately. <lfam>I might cheat and just turn of dynamic loading in xmlsec <lfam>There are bugs about this in centos, opensuse, alpine, macports, homebrew <smithras>Well hopefully with that much attention upstream will do something about it <lfam>Unfortunately the upstream seems quite hostile to bug reports about this <lfam>They always close the bugs with just a link to a primer on dynamic loading <lfam>It's not exactly helpful... <A[m]3>> no, 24h is not so long I think. <A[m]3>I tried to package one Qt app when I had a little time on New Year holidays but failed unfortunately. <smithras>A[m]3: qt apps are definitely harder to package than emacs packages! <lfam>NieDzejkob: I saw your message about the new version of Go <lfam>Is everything working okay with it? Like, did you try building the Go packages? <NieDzejkob>Yeah, I built like 4 packages with it without issues <ng0>sneek: later tell civodul: as someone with only uploader rights do you still want me to comment on the gnu guidelines (as email went to 3 groups of people)? <A[m]3>btw, my personal terminal keyboard shortcut of the day: <A[m]3>maybe helpful for args repeating. <g_bor[m]>I see a comment in the dhcp-client-service documentation that on should monitor udev events to see when the network is up. <lfam>NieDzejkob: One reason I didn't update it yet is that I found that Syncthing did not build with it, but that was a couple months ago <g_bor[m]>is there an example where I can see how it is done? <lfam>We can also add Go 1.13 alongside Go 1.12 for now. Go 1.12 is still supported upstream <NieDzejkob>lfam: weird. Go 1.13 fails on go-github-com-audriusbutkevicius-go-nat-pmp with "ice-9/boot-9.scm:222:17: In procedure map1: Syntax error: unknown location: unexpected syntax in form () <lfam>It may just need an update. I know that current versions of Syncthing are built with Go 1.13, but they seem to require downloading the dependencies at build time which is not something we can do <lfam>I'm sure we can make it work but I haven't had the time to look into it <apapsch>Ah, I just realised the build was done with %generic-search-paths, not the one I posted. I'm building now with the custom search paths, like I had intented late at night :-) <NieDzejkob>argh, wait, this is not on a clean tree, it's my buggy change interfering <mehlon>I must say, CTRL+R is probably the most useful keybind for bash I know of *janneke also enjoys the RET binding <apteryx>mbakke: do you think updating glib is OK on core-updates? <NieDzejkob>lfam: Looks like the default go will have to stay as 1.12 for now. syncthing and mongo-tools get some errors I don't feel like debugging any time soon <lfam>NieDzejkob: Okay. Are you comfortable sending a revised patch that adds 1.13 but keeps the default at 1.12? <NieDzejkob>*we're shipping quite an old version of mongo-tools ***jonsger1 is now known as jonsger
*smithras is going to sleep <bandali>so, is nckx the only european fella who hangs out here around this time? :-p