IRC channel logs

2020-01-28.log

back to list of logs

<bandali>submitted a couple emacs packages from my personal channel to guix-patches@; all feedback welcome and appreciated :-)
<Blackbeard[m]>bandali: :D
<bandali>Blackbeard[m], o/
***jonsger1 is now known as jonsger
<Gooberpatrol66>is there a way to get "go to definition" in guile without using emacs?
<Gooberpatrol66>inb4 "heresy"
<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>guile*
<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
<Gooberpatrol66>guix edit only works on package definitions
<drakonis>the migration to guile 3.0 broke the website
<Gooberpatrol66>i often don't even know what module a function is included from
<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>Hi Guix!
<efraim>hello!
<zzappie>Hi efraim
<zzappie>Is anywone having emacs-new throwing backtrace when edidting scheme files?
<DamienCassou>hi
<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]>hello guix!
<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.
<g_bor[m]>Thanks for help anyway.
<bricewge>g_bor: Nice! Do you care to share it?
<g_bor[m]>ok
<g_bor[m]> https://paste.debian.net/1128020/
<g_bor[m]>it is not tested yet
<bricewge>Thanks g_bor :)
<zzappie>DamienCassou: I dont know there is probably a reason why it is not installed. Probabbly because it is weights arround 100 mb
<DamienCassou>ok
<zzappie>you can find more info here https://guix.gnu.org/manual/en/guix.html#Locales-1
<DamienCassou>thank you
<zzappie>:)
<DamienCassou>zzappie: it didn't help though :-(. http://ix.io/28yg
<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]>(shepherd service)
<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.
<DamienCassou>> fix the service file to point to the new daemon
<DamienCassou>are you talking about the systemd guix daemon?
<g_bor[m]>yes
<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
<civodul>Hello Guix!
<zzappie>DamienCassou: the good news is you can experiment with guix without woryig about screwing up your system
<zzappie>hi civodul!
<g_bor[m]>hello guix!
<g_bor[m]>I've just noticed something strange.
<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...
<g_bor[m]>any idea what could this be?
<efraim>i'd assume something with the activation scripts. does opensmtp use postgres?
<g_bor[m]>No, it does not.
<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!
<civodul>hey g_bor[m]
<efraim>civodul: thanks!
<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
<DamienCassou>hi civodul
<civodul>hey, DamienCassou! :-)
<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]>Or should I go for the general case?
<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.
<jboy>civodul: I love the guix jupyter kernel so much! I noticed though that exporting the notebook seems to ignore the output of `;;guix pin` (see https://gist.github.com/jboynyc/5d0319f33e71427aa42a98c1a3a915cb).
<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>hey jboy, glad you like it!
<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>ah ok
<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?
<jboy>civodul: Will do!
<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
<g_bor[m]>ok, that seems reasonable.
<civodul>and only for home dirs not shared among different accounts (like /var/empty)
<g_bor[m]>I will have a look at that.
<civodul>cool!
<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>civodul: https://paste.debian.net/hidden/dfe0c92a/
<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>shtwzrd: ah! i've seen this problem on aarch64: https://issues.guix.gnu.org/issue/39266
<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>Good morning Guix!
<nckx>zzappie: It did. The pulled version, at least, last I knew the ‘guix’ package hadn't yet.
<smithras>good afternoon! :)
<civodul>zzappie: yup, see https://guix.gnu.org/blog/2020/guile-3-and-guix/
<civodul>heya nckx!
<nckx>civodul: Reading mail now 🙂
<zzappie>good evening nckx :)
<nckx>Oh good
<nckx> https://www.tobias.gr/freesoftware.png
<nckx>good good good.
<zzappie>civodul: ah i see realized it when got "incompatible bytecode kind" in repl
<civodul>nckx: :-)
<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.)
<zzappie>civodul: nope) I better had done it
<zzappie>but good news anyway
<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
<civodul>i'll send them a quick reply
<nckx>civodul: Did you see the ‘FY2019’ tab?
<nckx>Because I didn't 😉
<civodul>nckx: ah maybe not :-)
<civodul>nckx: ooh, wonderful!
<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>civodul: I'm back with an actual stack-trace. It looks similar to the issue you linked but I'm not really qualified to say. https://paste.debian.net/hidden/df1e1730/
<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...
<civodul>did you pass --debug?
<civodul>or just plain "guix pull"?
*jonsger sent a nckx ish patch in :P
<shtwzrd>civodul: `guix pull --debug=2 -c 1`
*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
<jonsger>so nothing wrong with that
<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.
<nckx>Eh.
<jonsger>nckx: I do start packaging a lot of stuff, but finishing (bringing upstream) only a fraction of them :(
<civodul>nckx: much appreciated anyway!
<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.
<zimoun>nckx: thank you, I am trying...
<nckx>I'm not sure what the semantics are, whether it appends or replaces the default CFLAGS.
<nckx>We'll see 🙂
***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
<Blackbeard[m]>Hi Guix ٩(◕‿◕。)۶
<nckx>Yep. I wonder why the flags differ between environments, though, but then I never debug builds that way 🤷
<nckx>Yo Blackbeard[m].
<Blackbeard[m]>nckx: hey
<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@.
<nckx>zimoun: ☝
<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?
<lispmacs[work]>cbaines: thx, I think that was it
<zimoun>lispmacs[work]: http://workflows.guix.info/
<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>Err, libxmlsec1-nss.so
<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>Or gcc-lib
<lfam>Any ideas?
<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>There's a few sections like this in the build log: https://paste.debian.net/1128097/
<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
<civodul>LD_LIBRARY_PATH is evviiiil! ;-)
<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
<lfam>It's not set
<civodul>lfam: one thing you could try is LD_DEBUG=files
<civodul>(it's verbose though)
*civodul rushes back home
<civodul>later!
<lfam>I tried that and it finds the library
<lfam>So weird
<lfam>The xmlsec1 package provided by Debian works okay here
<A[m]3>hello, Guix!
<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>s/to distracted/too distracted/
<smithras>A[m]3: oh just kidding it's in the latest guix revision! Someone beat me to it :)
<A[m]3>thank you. I'll check.
<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
<A[m]3>:)
<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
<A[m]3>strange logic.
<apapsch>Hi, please help me understand a RUNPATH issue. I'm building gccgo based on gcc-9, which fails RUNPATH validation. Using objdump on e.g. gofmt shows its own libgo is needed, but RUNPATH points to a glibc (http://codepad.org/ZF3IreWv). The recipe at the moment: http://codepad.org/U2PVhKM7
<apapsch>The last build lines are: http://codepad.org/uITVVEZI. I can share the full log (though I'm not sure where to drop it)
<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
<lucky_guy>Hi everyone! Can anyone help me build disk-image for arm board bananapi-m1 please? Tryed it by this tutorial https://guix.gnu.org/blog/2019/guix-on-an-arm-board/ but guix say that I forgot `(use-modules (#g549 #))'.
<lucky_guy>log: https://pastebin.com/bevbrvBj
<lucky_guy>config: https://pastebin.com/Tf5igU23
<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>Turn off
<lfam>There are bugs about this in centos, opensuse, alpine, macports, homebrew
<smithras>lfam: good luck!
<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.
<A[m]3>to pack
<smithras>A[m]3: qt apps are definitely harder to package than emacs packages!
<NieDzejkob>sneek: you there?
<NieDzejkob>sneek: botsnack
<sneek>:)
<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
<g_bor[m]>hello guix!
<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)?
<sneek>Okay.
<A[m]3>btw, my personal terminal keyboard shortcut of the day:
<A[m]3>Esc .
<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?
<NieDzejkob>let me see if that works
<lfam>Thanks
<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
<peanutbutterandc>Hello
<NieDzejkob>lfam: I'll try updating syncthing to 1.3.3
<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?
<apteryx>oh, you already did, great :-)
<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>lfam: Sure, I'll send one tomorrow
<lfam>Thanks :)
<NieDzejkob>on a related note, I noticed that wemongo-tools
<NieDzejkob>*we're shipping quite an old version of mongo-tools
<Digit> https://www.unicef.org/about/employ/?job=529210 "UNICEF Innovation Fund is looking for an opensource software tech advisor to support and advise the Fund’s growing portfolio of startups". saw this, and thought of gnu guys. :)
***jonsger1 is now known as jonsger
<smithras>A[m]3: I just submitted the emacs-org-drill patch: https://lists.gnu.org/archive/html/guix-patches/2020-01/msg01019.html
*smithras is going to sleep
<nckx>Digit: Cool! Thanks.
<bandali>so, is nckx the only european fella who hangs out here around this time? :-p
<lfam>Night shift